As announced before, Mule 3 will offer pattern-based configuration artifacts that will allow you to perform common configuration tasks with the least amount of XML. This first post opens the series where each of these patterns will be introduced.
The first configuration pattern we’d like to present is called: Simple Service. Its goal is as simple as its name suggests: provide a simple way to expose request-response services. In other terms, it is used to expose some business logic in a synchronous manner over the transport of your choice.
Core Features
Simple Service allows the deployment of SOA-style services on Mule in a short and elegant manner. Without further ado, let’s delve into examples that will illustrate the extensive capacities of this new configuration element.
That is all! An instance of SimpleMathsComponent is now accessible via a VM endpoint, which has been automatically configured to be synchronous (i.e. request-response). As usual, Mule will use a resolution strategy to find the best method for receiving the payload that has been sent to the service.
Of course, referencing global endpoints and components is also possible:
By the same token, transformers can be configured on the service:
Simple Service can also work with component configuration elements from any supported schema. The following shows a very convenient way to configure server stubs during functional tests:
Similarly, inbound endpoint and exception strategy can both be configured as child elements:
Now, if you’re a Mule 2 user, the following will bake your noodle: Simple Service, like all the new configuration patterns, can live outside a model. Knowing that models are useful for sharing common configuration properties, you may be wondering if we’ve lost it. The answer is that configuration pattern elements support inheritance (like standard Spring beans), hence offering a new but very familiar mechanism for sharing common settings across configuration elements. This is illustrated hereafter:
Pretty cool stuff, isn’t it? Actually the coolest part is that we have only scratched the surface of what Simple Service is capable of! Let’s now move on to more advanced features.
SOAP Services
Simple Service allows you to expose JAX-WS annotated components as SOAP services. All you need to do is add a type attribute and voila, your component can be invoked with SOAP calls.
Here is an example:
Note that if the transport used is HTTP, Simple Service will happily serve a WSDL document for requests whose paths end with “?WSDL”.
RESTful Services
Simple Service is also capable of exposing JAX-RS annotated components as RESTful services.
Again, using the relevant type is the only effort needed to start serving RESTful resources, as shown here:
If the component in the above configuration is annotated with @Path(“/weather-report”), then its resources will be reachable under this URI: http://localhost:6099/rest/weather-report.
JAX-RS services work with the HTTP and Servlet transports.
JAXB Support
Simple Service can handle JAXB serialized payloads. Nothing special is needed in the XML configuration:
But, for this to work, it is required that @Payload, a Mule-specific annotation, is used on the component:
XPath Support
Finally, Simple Service can also handle XML payload with a direct extraction of values via XPath expressions. Like with JAXB, nothing special is needed in XML:
But again, a Mule annotation, @XPath in this case, is needed for this to work:
Still Not Happy?
Because it presents a limited set of options, it is well possible that Simple Service doesn’t cover all the needs you may have. Bear in mind that, should you need a complete control over what you’re configuring, you can always opt to use a standard service or, even better in Mule 3, a flow.
Also, as said in the post presenting the configuration patterns, we would like the pattern-based configuration to be driven by our users as much as possible. So we welcome your feedback, improvement ideas and suggestions for new patterns in the forum we’ve created for that matter.
