Service Oriented Architecture is a currently popular industry term that generally refers to the composition of network enterprise information systems using an exchange of XML messages over the HTTP protocol.

The orthodox approach for building an SOA is to use industry-standard SOAP-based Web-Services. NetKernel provides a SOAP toolkit with client and server support as well as easy-to-use SOAP message processing tools. Enterprise architects are recognising that SOAP-based web-services are very complex and when compared to the use of simple XML over HTTP (also know as REST-web-services or REST-services), SOAP-based system may be expensive to build and maintain.

Whether you require industry-standard SOAP-based web-services, or fast and economical REST-services, NetKernel provides you the tools you need to develop industrial-strength SOAs. Our customers are astonished at the speed with which they can build an SOA because ultimately the challenge of an SOA implementation is XML message processing. NetKernel excels at XML message digestion, processing, and creation with its XML tools and integrated script language support.

SOAP Server

SOAP is an industry-standard message format and HTTP protocol binding for use with web-services. NetKernel provides protocol adaption, message routing, and a SOAP message slicing and dicing toolkit that makes developing SOAP-based services simple.

The diagram below shows a typical SOAP service implementation. A SOAP message is sent by a client to a URL endpoint. When configured in SOAP mode, NetKernel's HTTP transport extracts the service endpoint URI, the SOAP action URI, and the actual SOAP message. This information is issued as a normalized NetKernel URI service request which is routed by NetKernel's SOAP service mapper to the internal NetKernel URI-addressed service which actually implements the message processing.

Message processing typically consists of 3 steps: First, the SOAP message is unpacked (a range of dedicated SOAP processing tools that use a 'process-by-example' design are provided to simplify this task). Second, business logic is applied to the message data. Third, a response message is assembled (the NetKernel SOAP tools make this simple). Finally, the message is issued as the response and routed back to the requesting client.

Since service implementations are URI addressable services it is quite straightforward to transparently overlay pre-processing steps such as message validation, authentication and logging. This separation of concerns permitted by NetKernel's URI indirection means that each service implementation is simple and dedicated to just business logic.

REST Server

REpresentational State Transfer (REST) is an increasingly popular alternate approach to providing web-services. NetKernel's internal RESTful service architecture is a seamless fit with URL addressed web-service endpoints.

In a REST-service, a client posts an XML message to a URL-identified service. Upon receipt of a message, the XML data is internally passed as a parameter on a normalized NetKernel URI request. Next the internal implementation extracts data from the XML message and applies business logic before constructing an XML response message which is finally routed back to the client. As with SOAP, NetKernel provides a wide range of XML processing tools that make working with basic XML messages a breeze.

REST-services are easily and rapidly implemented with NetKernel. Compared to SOAP, REST-web-services use different URL addresses for each service, eliminating the need to extract the requested service name from the message. Also with REST-web-services, the XML messages are generally simpler. Because of these factors, REST-web-services are easier to test than SOAP, requiring only a web browser and clients are correspondingly simpler to develop.

NetKernel does not require an object model and the complexities of data binding to implement either SOAP or REST-based web-services. And, because of the way in which NetKernel maps the SOAP and REST approaches to internal messages, a single application or service can be exposed easily as both a SOAP and REST Web-service.