As announced before, Mule 3 will offer pattern-based artifacts that will allow you to perform common 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.

Simple Service

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.

No related posts.


5 Responses to “Pattern-Based Configuration: Hello Simple Service!”

From the Mule’s Mouth » Blog Archive » Pattern-Based Configuration: Hello Web Service Proxy! September 29th, 2010, 7:02 am

[...] }); }After the introduction of Simple Service, the configuration patterns series [...]

Emmanuel October 8th, 2010, 8:54 am

Will there be a pattern for asynchronous request response?

David Dossot October 11th, 2010, 9:53 am

The whole idea of Simple Service is to be an SOA-style synchronous service. Take for example a JAX-RS service: what you be the meaning of an HTTP call to it if no reply is returned to the HTTP client?

If you need an asynchronous message consumer, then using a Flow will provide you what you need.

Sri Basavanahally November 1st, 2010, 9:23 am

Hello David,

I have two mule applications each with its own service running in the same mule server. I am tryint to use component binding communication between the two using the vm connector. I want synchronous communication, But, I keep getting org.mule.api.transport.NoReceiverForEndpointException since it seems each service gets its own vm connector instance. How do I configure my services correctly to make this work? Note that I have this working fine in if both services are in the same mule application.

Thanks,
Sri

David Dossot November 3rd, 2010, 3:01 pm

Hi Sri,

Communication between Mule applications over VM is not supported. You should use another transport, like TCP, to establish such communications.

Cheers,
D.

Leave a Comment