Description on ODE
Apache ODE (Orchestration Director Engine) executes business processes written following the WS-BPEL standard. It has two communication layers. One is Axis2 integration layer and the other one is based on JBI standard. Those integration layers are used by ODE BPEL Engine Runtime for interact with the outside world. Axis2 integration layer supports for communicate via Web Service interactions. JBI integration layer supports for communicate via JBI messages. Here I have discussed about how to deploy an Axis2 service programatically in ODE during the initialization of Apache ODE.
Why deploying services at the initialization
We can deploy Axis2 web services in ODE in various ways. One way is just dumping and AAR (axis2 archive) in the services directory inside the ODE's deployment directory. In this method axis2 service can be deployed and undeployed them as user's choice. But suppose if we need to deploy a web service which provides a common functionality for all deployed business processes in ODE like ODE Management API then those kind of Web services need to be deployed during the initialization of ODE. ODE Management API is a axis2 Web service deployed in ODE during the initiation of ODE Run Time. This service monitor and manage all the business processes deployed in ODE. Another service which is deployed as same before is Deployment service which is used for deploy WS-BPEL processes. So if someone interested in developing a Web service which act as a generic feature for ODE like ODE Management API , that Web service must be deployed programatically during the initiation of ODE run time.
Basic overview of the process
How to deploy an axis2 Web service generally
There are several ways of deploying a axis2 Web service programatically.
1. One method is using the service archive file (AAR distribution).
Here we create an object of service archive file and a pointer to axis2 runtime or configuration context. Using the below code we can create the web service as follows.
This process is is almost same as putting the service archive file in the deployment directory.
2. Another method does need neither a services.xml nor a repository. In this POJO deployment it is only need axis2-1.4.jar and other dependent libraries.
Here MyService is the service implementation class. In this method as a services.xml is not existed, the degree of freedom for configure the service is very much less.
3. Final method does not need a services.xml, but it gives the freedom to configure the service such as by specifing message receivers etc. I prefer this method to deploy a axis2 Web service programatically during the initiation of ODE runtime.
Here when creating the service the message receiver is set and for more information refer org.apache.ode.axis2.service.ManagementService class. In org.apache.ode.axis2.service.ManagementService.DynamicMessageReceiver you may see how the service operations are invoked.
How to deploy the axis2 service in ODE runtime
Let see how to how to deploy an axis2 service programatically in ODE runtime. In this section it contains the ODE specific information which related to the axis2 service deployment.
ODEServer.java
To deploy a service in ODE runtime programatically org.apache.ode.axis2.ODEServer is normally used. Actually this class is the starting point for a execution of a ODE WAR distribution. If you look at the source code you may see almost all the basic resources are initialized in the org.apache.ode.axis2.ODEServer#init method.
In the init() method above syntaxes are used to deploy the Process ans Instance management service which is a basic management service in ODE runtime. In the above enableService() method the service deployment logic is implemented. That implementation can be any method as I described on the previous section.
Writing WSDL and the schemas and put the into the correct modules
Now the required WSDL and the related schemas should be placed in specific places on the ODE source in order to deploy the service.
Location for the WSDl - axis2/src/main/wsdl/
Location for the related schemas - bpel-schemas/src/main/xsd/
These resources should be kept in those specific packages, othervise while creating the WAR distribution required code generations, schema compilations will not be happened.
Creating .xsdconfig file for a schema
As I explained earlier schema files should be kept in a specific location (bpel-schemas/src/main/xsd/) in order to happen the code generation process succesfully. As well for each schema file it is required to created another file with the same name of the schema file and with .xsdconfig extention at the same location where the schema files are existed. This .xsdconfig file is needed for denote the target package for the generated bean classes. For example for pmapi.xsd the .xsdconfig file is pmapi.xsdconfig.
RakeFile Modification
After that, the "Rakefile" located at the root of ODE source should be configured. Rakefile contains executable Ruby code. Using that Ruby code, Apache Buildr will build the ODE source. In Rakefile it is need to mention about the newly added schema files in order to code generations and to populate the schema file in the WAR distribution. At the following places in the Rakefile you need to modify the Ruby code based on the added schemas.
Note: If you add the schema definitions in the WSDL itself, then there is no way of bean geaneration for thoes schemas.
Compilatation of schemas and bean class generation is handled by the following Ruby code snippet.
Rebuilding using buildr
Now re-building the source code using Apache Buildr, a WAR distraibution will be generated with the modifications you made.
Apache ODE (Orchestration Director Engine) executes business processes written following the WS-BPEL standard. It has two communication layers. One is Axis2 integration layer and the other one is based on JBI standard. Those integration layers are used by ODE BPEL Engine Runtime for interact with the outside world. Axis2 integration layer supports for communicate via Web Service interactions. JBI integration layer supports for communicate via JBI messages. Here I have discussed about how to deploy an Axis2 service programatically in ODE during the initialization of Apache ODE.
Why deploying services at the initialization
We can deploy Axis2 web services in ODE in various ways. One way is just dumping and AAR (axis2 archive) in the services directory inside the ODE's deployment directory. In this method axis2 service can be deployed and undeployed them as user's choice. But suppose if we need to deploy a web service which provides a common functionality for all deployed business processes in ODE like ODE Management API then those kind of Web services need to be deployed during the initialization of ODE. ODE Management API is a axis2 Web service deployed in ODE during the initiation of ODE Run Time. This service monitor and manage all the business processes deployed in ODE. Another service which is deployed as same before is Deployment service which is used for deploy WS-BPEL processes. So if someone interested in developing a Web service which act as a generic feature for ODE like ODE Management API , that Web service must be deployed programatically during the initiation of ODE run time.
Basic overview of the process
How to deploy an axis2 Web service generally
There are several ways of deploying a axis2 Web service programatically.
1. One method is using the service archive file (AAR distribution).
Here we create an object of service archive file and a pointer to axis2 runtime or configuration context. Using the below code we can create the web service as follows.
This process is is almost same as putting the service archive file in the deployment directory.
2. Another method does need neither a services.xml nor a repository. In this POJO deployment it is only need axis2-1.4.jar and other dependent libraries.
Here MyService is the service implementation class. In this method as a services.xml is not existed, the degree of freedom for configure the service is very much less.
3. Final method does not need a services.xml, but it gives the freedom to configure the service such as by specifing message receivers etc. I prefer this method to deploy a axis2 Web service programatically during the initiation of ODE runtime.
Here when creating the service the message receiver is set and for more information refer org.apache.ode.axis2.service.ManagementService class. In org.apache.ode.axis2.service.ManagementService.DynamicMessageReceiver you may see how the service operations are invoked.
How to deploy the axis2 service in ODE runtime
Let see how to how to deploy an axis2 service programatically in ODE runtime. In this section it contains the ODE specific information which related to the axis2 service deployment.
ODEServer.java
To deploy a service in ODE runtime programatically org.apache.ode.axis2.ODEServer is normally used. Actually this class is the starting point for a execution of a ODE WAR distribution. If you look at the source code you may see almost all the basic resources are initialized in the org.apache.ode.axis2.ODEServer#init method.
In the init() method above syntaxes are used to deploy the Process ans Instance management service which is a basic management service in ODE runtime. In the above enableService() method the service deployment logic is implemented. That implementation can be any method as I described on the previous section.
Writing WSDL and the schemas and put the into the correct modules
Now the required WSDL and the related schemas should be placed in specific places on the ODE source in order to deploy the service.
Location for the WSDl - axis2/src/main/wsdl/
Location for the related schemas - bpel-schemas/src/main/xsd/
These resources should be kept in those specific packages, othervise while creating the WAR distribution required code generations, schema compilations will not be happened.
Creating .xsdconfig file for a schema
As I explained earlier schema files should be kept in a specific location (bpel-schemas/src/main/xsd/) in order to happen the code generation process succesfully. As well for each schema file it is required to created another file with the same name of the schema file and with .xsdconfig extention at the same location where the schema files are existed. This .xsdconfig file is needed for denote the target package for the generated bean classes. For example for pmapi.xsd the .xsdconfig file is pmapi.xsdconfig.
RakeFile Modification
After that, the "Rakefile" located at the root of ODE source should be configured. Rakefile contains executable Ruby code. Using that Ruby code, Apache Buildr will build the ODE source. In Rakefile it is need to mention about the newly added schema files in order to code generations and to populate the schema file in the WAR distribution. At the following places in the Rakefile you need to modify the Ruby code based on the added schemas.
Note: If you add the schema definitions in the WSDL itself, then there is no way of bean geaneration for thoes schemas.
Compilatation of schemas and bean class generation is handled by the following Ruby code snippet.
Rebuilding using buildr
Now re-building the source code using Apache Buildr, a WAR distraibution will be generated with the modifications you made.
No comments:
Post a Comment