|
|
Featuring step-by-step instructions, this how-to guide demonstrates the componentization capabilities of WSO2 Carbon.
WSO2 Carbon (Middleware à la carte), based on OSGi, is the base framework for the WSO2 product platform. Carbon promises seamless integration of WSO2 products including WSO2 WSAS, WSO2 Registry, WSO2 ESB and WSO2 BPS. To show this integration in practice, the following article describes how to add ESB functionalities to WSAS. In addition, because the WSO2 Registry is integrated into WSAS and all the other products by default, this use case actually shows the integration of three total products (WSAS, Registry and ESB). The use case featured here is also explained in the Adding Mediation to WSO2 WSAS screencast.
WSO2 Carbon is an OSGi-based platform implementation on which all the Java products by WSO2 are based. Carbon provides the core runtime for the features of these products to be implemented as components, which makes each and every product simply a Carbon runtime and a set of feature components. For example, WSO2 ESB by default ships with the Mediation component, Proxy Services component, Task component, etc...
This enables WSO2 products to be highly extensible and customizable, which is one of many advantages of Carbon. Most interestingly, you could take features from one product and apply those features on to another product to customize the behavior of the middleware application. With this, WSO2 provides the ability to adapt the middleware to your architecture where as in many other cases it adapts your architecture to the middleware.
WSO2 Web Services Application Server (WSAS), is the service hosting environment of the WSO2 SOA stack. It provides the ability to host Axis2 services, Axis services, EJB services, Data services, POJO services, Spring services and many more. Additionally, it provides the ability to configure the Quality of Service (QoS) parameters of the hosted services.
WSAS also provides a set of monitoring tools to monitor the system such as, SOAP Tracer, System Statistics, System Logs and so on.
Mediation in its English meaning is the conflict resolution between two parties. In the case of inter-device communication, it refers to the conflict resolution in messaging between client and the server. If you design the Service Oriented Architecture (SOA) for your enterprise in a way that it suffices all the client requirements, then you might not need mediation. However, the fact that the world is evolving either requires you to upgrade your SOA implementation periodically, or you need mediation to adapt your implementation to current requirements.
Most organizations have legacy services that they cannot change, but they require those legacy services to be adopted by the current SOA. For example, you may want to add security to an existing non-secure service in order to make it usable by the current architecture. In this way mediation is vital for a successful implementation of the SOA, as it provides much-needed extensibility for your enterprise.
Mediation on WSAS services will be different from ESB layer mediation, in which case there is a third party who is doing the mediation between the service invoker and the service host. The mediation capability that can be added to WSAS brings the mediation to be bundled into the service host.
![]() |
| Figure 01: ESB layer mediation between service invoker and service host |
![]() |
| Figure 02: Service host has mediaiton bundled to itself |
The Figure 01 illustrates how you can use the ESB to mediate while the Figure 02 shows the scenario that we are trying to explain in this particular article, where the mediation capability is built into the service host (WSAS).
Adding mediation to WSAS is very straight forward, and described in the following set of steps. The Carbon platform provides the technology to make it so easy to add mediation functionality to WSAS.
![]() |
| Figure 03: Console output when starting the WSAS |
![]() |
| Figure 04: WSAS administration console |
![]() |
| Figure 05: WSAS administration console with mediation |
Adding mediation to an existing service is just a three step process in which you define two sequences for the incoming and outgoing messages in the sequences tab, and then create the association of those sequences to the service through service parameters.
![]() |
| Figure 06: Add Log mediator to the "hello_in" sequence |
![]() |
| Figure 07: Configuring the Log mediator |
Follow the above steps to create a sequence named "hello_out", with a log mediator with "Full" log level and a custom property with the name OUT-MESSAGE and value ********** Out message logged ***********. Save this sequence as well using the bottom button panel. Now you should see these two sequence on the sequence listing page as shown in Figure 08
(Note: WSO2 ESB by default does not persist sequences, and if you need these sequences to be present on the next startup as well, go to the Synapse tab and use the Save button to persist the sequences)
![]() |
| Figure 08: Sequences List |
![]() |
| Figure 09: HelloService service dashboard |
![]() |
| Figure 10: synapse-handler-1.30 module engaged |
![]() |
| Figure 11: Service parameters configuration |
These "hello_in" and the "hello_out" are the sequences that we have created in the above two steps respectively and we have now created the association of the sequences to the "HelloService"
Now we have set up the "HelloService" for mediation at the service host side itself and you could use the Try-It tool to try this service which will generate a web based client to try this service. To invoke this service through Try-It;
![]() |
| Figure 12: Try the HelloService |
![]() |
| Figure 13: System Logs |
(Note: here you can see three entries with the same log, one for the SERVICE_LOGGER and the other two from the Log mediator to the console log and standard output log)
This article has shown how we can use the mediation functionalities on the service hosting environment, and how this mediation can be very powerful in certain cases. We have only explored logging the message at the mediation, but we could easily extend this to provide more interesting and complex mediations including message transformation, message validation, message filtering and throttling, response caching for time consuming steady services, database reporting and so on.
This particular scenario can be directly applied to the BPS processes as well because they are again services. In the same way of adding the mediation functionality to the WSAS, it is trivial to add the service hosting capabilities to the ESB as well. You could store all these configuration bits in the Registry built in to each of these products so that it demonstrates the integrity between Registry as well. Finally Carbon platform lets you manage the middleware for your exact requirement.
Note: Even though we can have everything in one single server it may not be the best deployment model for your architecture, so please be careful in designing the deployment by customizing the servers.
Ruwan Linton Product Manager - WSO2 ESB WSO2 Inc ruwan AT wso2 DOT com