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.
The TroubleTicket application beeing exposed as a web service, it is automatically connected to the JBI bus (NMR) thanks to the JavaEE SE. So, the service provider is in place, the first prototype can now be realized. It simply consists in connecting the two partners to the bus to have a base for enhancing this SOA system or composite application. As a result of this first stage, the web service client will not access the TroubleTicket service directly from its endpoint, but will request the service through the JBI environment.
The second part of this work is to connect the client to the bus. Here I implement a web service client, communicating through XML SOAP messages over HTTP. This client is similar to the one realized for testing alone the created web service, with the difference that it invokes another URL: the real service implementation is now unknown from it, it only see the TroubleTicket service offered by the orchestration module, which plays the role of an intermediary between consumer and provider: so, the service provider is fully transparent for the client.
This composite application involves three JBI modules:
- The HTTP/SOAP BC: acting as a connector module for the web service client to access the bus;
- The BPEL SE: managing the business process, it is in charge of the service providing;
- The JavaEE SE, acting as a bridge between the JBI bus and the application server, connecting the TroubleTicket service to the composite application environment. This module does not need to be packaged in the final JBI application accessing the TT web service it offers. The JavaEE SE is part of Sun Application Server. It is automatically plugged in the JBI bus (NMR) local instance.
Service Engines are the core a JBI composite application. Needed Binding Components just need to be started in the JBI environment. They will be automatically instanciated at deployment depending on the partners you have defined in your business process. So main step here is to developp the BPEL module. After that, the JBI application can be build and deployed, before beeing tested.
This composite application remains very basic, but it is not only a base for the road to OSS/J SOA, but it also well illustrates a SOA advantage: integration decoupling. In others words, it shows how two partners can communicate without knowing each other, and even without interact through the same protocol ! Moreover, SOA also enables to manage business processes. Each process is defined separately from the actors of the interactions building this process. Whereas classical point-to-point architectures have no global view of a process realizing a given function, SOA provides a way to globally manage the processes.
Netbeans offers a web service testing web interface, browse URL: http://localhost:8080/
But this is not the case here. Another solution is to create a specific client allowing to handle with complex types, more precisely a Java client and a JAX-WS tool. To that purpose, the only requirement is the URL of the WSDL file describing the service to test. This service description is used by the wsimport tool to generate client web service artifacts;
The client retrieves service port from wsdl file, then it can invoke successively different methods exposed.
Note that the 'JVTTroubleTicketservantService' class is unrecognized by Netbeans because it is a JAX-WS generated class. After the needed classes have been retrieved from the service description during 'wsimport' execution, there no problem for the client to compile.
Compiling the client, meaning wsimporting artifacts from service WSDL description, building and running it, can be carried out by adding following ant targets:
Execute these compile-client and then run-client targets. This will test the exposed methods from the web service. With just a few manipulations, you have just created a web service Java client with the JAX-WS 'wsimport' tool.
Now the TroubleTicket application has became a WS, the JavaEE Service Engine has registered the new endpoint. Let's begin with the core of the first prototype : the migration of a TroubleTicket system into OpenESB.
OSS/J specifications define contracts between OSS applications. It only uses interfaces as methods signature. Here is the example for creating a TroubleTicket from its value:
where TroubleTicketValue and TroubleTicketKey are both OSS/J interfaces from the TroubleTicket specification (JSR 91).
JAX-WS tool generates so called 'artifacts', i.e. the WS endpoint. More precisely it generates WSDL and XSD files matching the defined web service, and java classes able to convert an xml data file to a java object and vice versa. To that work, JAX-WS uses another tool, JAX-B, that binds xml types with java types.
JAX-B needs to instanciate classes (can't be done with interfaces) to encode and decode XML from / to Java.
It may exist several solutions to solve this issue. JAX-B experts have already considered it and given three solutions to the JAX-B interfaces issue. You can get more detail at the online unofficial JAX-B guide.
The one working in the case presented below is with the @XmlJavaTypeAdpater. In simple words, the @XmlJavaTypeAdapter annotation allows you to say JAX-B : "Whenever you found this Interface ItfA, use the implementation class ImplA instead". Its usage involves two things : annotation of the interface, creation of an adapter class with two methods for (un)marshalling between the interface and the implementation class.
Here is the example for the TroubleTicketValue interface (header)...
...and its Adapter (without exceptions handling):
A design phase is necessary to determine the mapping between interfaces and their corresponding implementations.
The interfaces beeing annotated, the Adapter classes must be created. Coding manually the adapters is a bit tedious, however they can be easliy generated.
Wsgen target can now be executed again to verify artifacts are well generated ; all the previous errors shall disappear. This step is not mandatory, it is just for verification purpose ; actually, the wsgen tool is automatically executed at deployment by the application server for generating the web service artifacts. You can verify the service is well deployed by accessing its WSDL description from a browser. To ensure its works fine, a test stage is preferable.
This work illustrates well JAX-WS use and facility: from an existing J2EE 1.4 application, and with a few manipulations, a corresponding web service has been easily created.
The Web Service implementation class is a session bean 3.0, annotated with the @WebService tag. Concretely, this EJB 3.0 will access the existing Session Bean of the TroubleTicket application and invoke corresponding methods.
The needed annotations are :
- @Stateless: to specify this class is a Stateless Session Bean;
- @WebService: to indicate JAX-WS this file is a web service, so that artifacts will be created;
- @WebMethod: for JAX-WS too, indicating that this method is exposed. This annotation is optional: in fact, every method of the endpoint will be exposed.
Note an important modification relativ to the EJB access : when accessing an EJB 2.1 or previous version from an EJB 3.0, the object returned by the lookup function can not be casted. The use of an intermediary method, javax.rmi.PortableRemoteObject.narrow method is mandatory, as specified by the EJB 3.0 specification.
Netbeans handles automatically the @WebService annotation by creating the ant target 'wsgen-generate' for producing the endpoint of this web service. As this point wsgen execution should be possible. But JAX-B -a sub-tool of JAX-WS, in charge of the binding between XML and Java types- will encounter obstacle to compute interfaces definitions: error message like "JAX'B can't handle with interfaces..." will be generated. Next post explains how to handle the generation from interfaces definitions.
I explain here the broad outline of exposing an enterprise application as web service with JAX-WS. More precisely, I detail the different steps to follow to convert an existing J2EE 1.4 application, namely the Sun TroubleTicket (OSS/J API, JSR 91) Reference Implementation 1.0.1, as a web service.
JAX-WS is a tool that helps you to create a web service by converting XML data into Java instances or vice versa. It offers two ways for creating a web service:
- a) either from the service description (WSDL file), it generates the web service implementation ("wsimport" tool);
- b) or from the Java Bean implementing the web service (endpoint class), it generates the service description ("wsgen" tool).
In each case, web service artifacts are generated. There are java classes enabling at runtime the transposition between XML (more precisely SOAP messages) and Java objects (corresponding instances).
Because of the legacy, I use here the second approach. The objective is actually that clients -i.e. telecommunication service providers- can reuse their existing systems. They want them to be exposed as web services to be able to plug them into an ESB, aiming at building a SOA OSS system.
Now, starting with the Java implementation to generate the WS artifacts, there is still two approaches:
- either to interface the existing Session Bean: it means to create a new EJB 3.0 (required by JAX-WS ) for the web service implementation, exposing the desired web methods, this EJB 3.0 will then communicate with the existing Session Bean;
- or to interface directly the existing entity bean (bean called by the session bean): it implies to convert the existing Session Bean in the web service implementation (in annotated EJB 3.0) so that the web service implementation class access directly the entity bean.
Here I choose to implement the first solution : it has indeed the advantage that the application can be accessed by two ways: as a web service thanks a SOAP message over HTTP or as a classical enterprise application by a classical client such as a servlet, an applet, Corba Remote Call, etc.
The web service exposition is composed of three main steps, each one detailed in the next posts:
1. Creation of the Web Service implementation class
2. Annotation of the code
4. Test of the exposed Web Service
First prototype is the base of all the others: the migration of a Trouble Ticket system into OpenESB.
A trouble Ticket system has basically two actors :
- a service provider, exposing the OSS/J TroubleTicket API (JSR 91), and here implemented by a JavaEE enterprise application;
- a service consumer or TT client, allowing to call the TroubleTicket service.
The work here consists in migrating this system into OpenESB, that is to say to connect each part with the bus so that the exchanged messages forward through the NMR (JBI bus).
To plug an Enterprise Application into the NMR (Normalized Message Router), in other words the JBI bus, we can not use directly the classical Session Bean unless we develop a specific JBI component. There is a «Java EE Service Engine» that connects automatically all the local EJB exposed as web services to the JBI environment.
On the client side, I will simply use a web service client, connected to the JBI bus thanks the HTTP/SOAP Binding Component.
So first step will be to expose the Trouble Ticket system as a web service so that the JavaEE Service Engine can access it. This work is a real case for the service providers. Actually the OSS layer of service providers of the telecommunications industry is often a complex system, composed of existing applications integrated together with the time. Such clients are interested in cost saving, thus in migrating their OSS system into a SOA. But they want to reuse their existing systems. Whenever a client has such an enterpise application providing a service, it will need to expose it as a web service before beeing able to make it part of a JBI composite application.
The Enterprise Bus OpenESB, including a JBI framework, is runnning over Sun Java System Application Server. Basically you just need to install the following:
- JSE 5
- Sun Application Server 9.0PE ('Glassfish')
- Open-ESB
But if you aim at developing composite applications, you can use the Netbeans IDE. OpenESB project not only focus on implementing a JBI-based ESB, and other JBI components (Service Engines and Binding Components), it also includes Netbeans SOA plugins, offering a BPEL design interface or a WSDL editor for instance. The SOA modules are included in the Netbeans Entreprise Pack 5.5, for the moment only available as Early Access.
Since JavaOne 2006, you can free download the "Java EE 5 Tools Bundle Beta" pack:
As explained before, the prototypes I am going to developp are a proof of concept of OSS/J SOA. In other words, they will show service providers how to migrate their current infrastructure to a SOA architecture for their OSS.
Steps of my project are exactly the migration stages, each stage beeing an enrichment of the previous one.
1. Migration of a Trouble Ticket system into OpenESB.
2. Addition of business logic into to the previous process : consumer and provider have not the same data model, business logic allows the conversion of the transfered data.
3. Enrichment of the TT process with a second service provider ; additon of a business logic to route the messages to the right provider depending on the messages format.
4. Addition of a "Rule Engine" (RE) into the process.
5. Creation of a second bus to simulate a B2B solution between two companies.
A lot of evolution of these basic scenarios can be considered. Perhaps the demo will be improved to use a portal and portlets components for the service consumer to have a more convivial presentation.
I will first begin with the installation of the development environnement...
Hi all,
New comer at Sun today is the end of my first week, but it is also the day of my blog's birth.
I am here for the next six months, working as intern in the OSS/J Telco team. Its objective is to promote Sun technologies and products for implementing SOA in the middelware of the telecommunication industry, the OSS.
OSS stands for "Operational Support Systems". OSS designates the software layer of a Telco service provider, situated over the hardware layer. The OSS contains all the applications and the processes of a service provider allowing it to apply a "business model" over the services it provides, i.e. to activate, to watch, to charge, etc. these services.
Currently OSS infrastructures have been developed over the years and have evolved with the needs. A few years ago no standard had been defined. Thus heterogeneous integration was not possible, each service provider was locked into one vendor. This was the reason for OSS/J Initiative birth, in which Sun takes part. OSS/J's goal is to define standard interfaces defining contracts between the applications. Then other OSS specific standards were defined. There are now gathered by the TMF under the name of NGOSS, standing for Next Generation OSS. But this first standardization step is not enough for solving interoperability and integration problems. These systems remain complex, they still have "point-to-point" architectures. No interoperability between plateforms is guaranted, architectures are not flexible.
Sun solution to this issue is to introduce a Service Oriented Architecture, SOA, in the OSS layer. The final goal is to have all the OSS processes (also defined as standard processes, called eTOM) implemented in the form of composite applications using standardized interfaces (OSS/J interfaces) so that all the different components of a process can be integrated. Beeing modular, such an architecture provides flexibility and is easy to maintain. It will represent huge save for the service providers.
Sun is leading "Java Business Integration" (JBI), a standard specification (JSR-208) for composite applications. A JBI based bus, (OpenESB), has also been defined to orchestrate SOA processes. It is developed as an open-source project.
My goal during this internship is to developp demos illustrating step by step how to migrate a point to point OSS/J architecture to a SOA JBI based one.
On the road !
