As we say in france "Every good things have an end".
Working on this project during a six month internship has been really interesting, even impassioning! These prototypes are just a SOA OSS base. Too bad, I would have carry on with pleasure.
Good luck to OSS/J and SOA partnership!
The starting point beeing a simple SOA prototype involving a TroubleTicket (TT) service consumer and TT service provider, I will now add data transformation within a XSLT SE.
First part of the development is to create the XSLT module. This includes three steps:
- First the WSDL description, with input and output types of course, and all the others required tags (Messages, Port Types, Binding, Service and finally Partners) must be written.
- Then the XSLT transformation has to be implemented. It specifies the data returned by the service (in a file with the ".xsl" extension). A XSLT transformation enables many data manipulations ; for example setting a null field to a default value if this field is required by another service provider, changing date format (from one field to three), or even setting a field with a value get from a database.
- Lastly, a XML configuration file called "xsltmap" must be provided.It specifies amongst other things the request type, and other information relativ to the input fo this XSLT service. Here is a concrete simple example of such an XSLT map in this TT particular case:
Of course, the BPEL module orchestrating the process has to be modified so that this data transformation module is called before invoking the TT service provider deployed in the local application server and available through the JavaEE SE.
Finally, the second composite prototype can be deployed and tested, in the same way as before. By changing client data format to corrsepond to the one expected by the TroubleTicket service offered by the BPEL module, same client can be reuse for this test.
This application illustrates logic decoupling enabled by SOA. In particular, data format transformation is here realized inside the SOA environment, so that it is completely transparent for each actor (service provider and consumer).
SOA offers multiple advantages solving intergation problems. In particular, it enables logic decoupling. More than business process management, illustrated in the migration stage of this project, it also enables to decouple data transformation logic for instance. This is what I illustrate here on an OSS/J TroubleTicket system.
This scenario relies on client real use case: having a service consumer and a service provider with different data format, Telecom service providers were previously obliged to add specific module(s) inside their OSS applications for data transformation and depending from the interaction partner data format. SOA is a real revolution for simplifying interoperability.
The final prototype architecture counts five JBI modules as shown below:
Next posts explain how to developp such a composite application from this first created prototype.
