The SOA architecture stipulates the creation of a repository of standardised and reusable services which can be composed or integrated into an aggregate service which automates a business process. The Enterprise Service Bus is an essential component in a SOA and is the ideal hosting environment for Service Orchestration. In this post I’m going to describe service orchestration with a Hospital Admissions Example.
Let´s suppose we are a Health-care Provider and are implementing a SOA architecture. Having built up a repository of services we are in a position to automate the Hospital admission process by exposing a new service, AdmissionService, which will orchestrate (integrate) the PatientService which manages demographic records of Patients, the EHRService which manages Episodes of Patient care at the hospital, the BillingService which manages the financial costs associated with the Patient care and the AuditService which is used to monitor the use of services. An external InsuranceService will also be used in order to determine the Patient’s admissibility. All of these orchestrated services are highly reusable within our SOA precisely because they are agnostic to any particular business process within the hospital and can thus participate in any orchestration which requires their use. Note how within a SOA, those services which either attend directly to a business entity or address cross-cutting concerns as a utility are the ones that are naturally composable in this way.
As much as is possible the Services in our architecture should have a standardised contract. We have used the Document Literal Wrapped design pattern to author our Wsdls and their messages. As a rule, each request messages matches the name of its corresponding operation and the response messages append ‘Response’ to the same name. We take this standardisation a step further by extracting all of the message definitions from the Wsdls (which still reference them) and centralising them in a common schema so that they all share a common namespace:
Note how we have included the version number in the namespace in order to facilitate service versioning. This also helps in the authoring of our xpath expressions (see below): they will usually navigate from a root element pertaining to the message namespace.
When different systems are integrated together, it is almost inevitable to talk of transformation. This basically covers the requirement for systems which “speak different languages” to be able to communicate with a sort of “translation” or transformation in between. You can see this in our example as each call to the orchestrated web-services involves a transformation using Data-Mapper. It is important to note however, that transformations ought to be kept to a minimum in a SOA architecture and a Canonical Model ought to be designed which can cover the areas of the business addressed by the architecture. This model would have a common usage across the set of services (parts of it at least) and would facilitate the minimisation of transformations. We have done this here by centralising all of our business entity model definitions in a single versioned schema with the namespace
You can see the convenience of our separating the modelling layer of the schemas from the messaging layer. Note how the admitSubjectResponse, createEpisodeResponse and the createBill messages make reference to the Episode element defined in the model namespace and the Bill element in the same model is referenced by the admitSubjectResponse and of course the createBillResponse messages.
As we use the Mule Expression Language xpath() function in our application, we must configure mule to recognise the said namespaces by the following declaration:
Note how we included the namespace of the Insurance web-service messages.
Java or Xml
Fundamental to the exposure and consumption of SOAP-based web-services in Mule, is the SOAP Message Processor. This allows you to do both. It will also apply automatic schema validation against incoming SOAP envelopes, apply Security (SAML, Username-Password tokens, signing and encryption). Very conveniently it also affords you the choice between pure Xml processing or Java.
If you choose Java (the JAX-WS service and client configurations), then you will need JAX-WS annotated classes on your classpath which will represent the service interface, the messages passed to and from each operation and (optionally) a service implementation. This last point is worth noting. You are not obliged to provide a Java implementation if you go down the JAX-WS route. Your flow can just as well act as the implementation of your exposed web-service. All the required Java classes can be generated by Studio by simply importing a WSDL file.
If you choose Xml, as we do in this example (the Proxy service and client configurations), then you need only consider whether you want the Proxy service to pass on the entire Soap Envelope to the rest of your flow in which case you need to specify ‘envelope’ as the payload. Otherwise, choose ‘body’ as the payload which will mean that you expect to receive the child element(s) of the Soap Body from the Proxy service and will pass the same to the Proxy client. Proxy client will know how to wrap the message you pass in this case with the Soap Envelope.
Here’s the admitPatientService flow which exposes our web-service.
Note that we configure the following essentials on the SOAP Message Processor:
- operation Proxy service, which configures the Processor to expose a web-service in pure Xml mode
- service the name of the service element in the WSDL
- port the name of the port element inside the service in the WSDL
- namespace the targetNamespace of the WSDL
- wsdlLocation relative to src/main/resources
- payload body in this case as we want it to give us the element inside the Body
The Mule Expression Language evaluates any X-Path expression by way of the xpath() function. As we are processing our messages in pure xml, we need to exploit the use of X-Path in order to do the content based routing required in order to distinguish the different operations being invoked on each web-service. We exploit the Contract Standarisation explained above for the content based routing needed to distinguish between operation calls. Take a look at the Mock EHRService implementation we provide:
Note how we extract the element name of the in-coming message and then apply the choice based on that name.
Mule as Webservice client
Orchestrating a number of web-services presupposes the existence of deployed webservices somewhere. Taking it as a given that Mule Enterprise is being used as the Enterprise Service Bus, then these will be deployed in their own applications but they should adhere to the standardised design of Messages agreed for our company. If they are external to the company or even deployed on a different platform like .Net, it makes no difference to us. We need to consume them all in the same way and provide them with a SOAP Envelope which adheres to their WSDL.
Note how we invoke sub-flows which encapsulate both the SOAP Message Processor (Proxy client) and the HTTP Outbound Endpoint. It is necessary to ensure that these two are kept in sub-flows, as the SOAP Message Processor needs to take the response of the Http outbound and do some post-processing on it, like marshalling, error handling, etc.
Note that the configuration of the Proxy client is the minimal choice between body or envelope for the payload:
A Word on BPM
We have mentioned business process quite a bit in this post. This is because Business Process is a first-class citizen in the Service Oriented Architecture. Whom do those services serve, if not Business Process? IT must allow Business Process to change and be agile enough to adapt to those changes. Such agility and adaptability is one of the goals of SOA. But when one talks of Business Process in the context of a discussion on the Enterprise Service Bus, the use of a Business Process Management engine usually comes to mind and sometimes people can understandably confuse the role of the two.
When we speak of business process automation in this post, we obviously make no reference to BPM as the solution we present resides entirely on Mule Enterprise. That is not to say that we disregard the use of such software, rather that there is absolutely no need for it in the use-case that we present here.
It would be good to clarify quickly when we do recommend to use BPM and ESB together: when there exists the need to have some sort of human intervention “mid-stream”–at some point in the process–a sort of sign-off. This results in the technical requirement to manage long-running transactions. BPM engines excel in this space and so, if our orchestration required human intervention, it could be hosted and deployed on any BPM engine. An example might be that before the invocation of the BillingService, the criteria for calculating the cost needed a human data-entry on a UI. All that said, while in this new scenario, the orchestration would move to a BPM engine, the composed services would continue to reside on the Enterprise Service Bus which would be invoked by the BPM engine.
Thus in a SOA, you can see that the essential component is the ESB. Whether it be alone or in collaboration with a BPM engine, Mule excels in its role as the backbone of your Service Oriented Architecture.
To speak of service orchestration is necessarily to speak of integration. Mule is the backbone in SOA architecture both to host services and to orchestrate existing services into a new aggregate service which typically represents a business process. We have deployed this application to cloud-hub. You can see the design of the wsdls and the schemas at
The source for this application can be found here.