A design goal of bexee is to be easy to use in order to make it interesting for experiments with business processes and BPEL in general. We therefore decided to provide a hot-deployment mechanism in bexee. The main idea of such a mechanism is to ensure a simple way for the users to deploy business processes in bexee without the knowledge of the internals of bexee. It will only be necessary to describe a business process in BPEL, to define the Web Service descriptors for this service (WSDL) and to provide partner link information (also in WSDL). The user only has to deploy these files containing the mentioned descriptions in bexee and the process is automatically made available for use.
The contrary to this hot-deployment mechanism would be, to require from the user to generate java code for invokation of partner Web Services, then to generate Web Service Stubs for the invokation of the own Web Service interface (as for all Receive BPEL activities), to compile generated code, package it and to add it into the dynamic classpath of bexee.
In our opinion, an important purpose of the BPEL standard is to provide a language for business process modelling which is abstract enough to make it unnecessary for the modeller to know a programming language like java. The business process modeller needs certainly to have a good knowledge of the BPEL language, XPath and Web Services, but needs not to concentrate on how exactly the modeled processes will be executed or represented within a BPEL engine.
The main purpose of a hot-deployment mechanism is to shield the user from the implementation details of bexee. Providing a hot-deployment mechanism removes the necessity for a user to have a in-depth knowledge of code generation, compilation, packaging, etc. and the advantages of decoupling the BPEL standard from the underlying technologies would get lost.
In order to deploy a business process, a number of documents are needed. The user has to prepare the BPEL document itself and also needs to create a WSDL document, describing the process activities which might be invoked (Receive activities). If other Web Services are invoked the user also needs to provide their WSDL description, possibly enriched with partner link information.
bexee provides a simple Manager Web Service which can be used to deploy the prepared documents.
Making the Manager Web Service available at Axis bootstrapping-time allows us to use it as soon as we deploy bexee into the servlet container i.e. Tomcat.
The Manager Web Service is responsible for deploying new BPEL processes to bexee and deploying them as Web Services to Axis. As already mentioned above it is necessary to pass in the BPEL document itself, accompanyied by one or more WSDL documents describing the BPEL service itself as well as the referenced Web Services.
As soon as the documents (BPEL and WSDL) arrive at the Manager service, they will be parsed and validated. The next step is to extract the service information out of the process' WSDL so that an Axis deployment descriptor can be created, to which the new process is finally deployed as a Web Service by adding itself to the Axis engine configuration. The parsed documents will then be made persistent.
Note that the Manager doesn't store the information directly into persistent storage but rather uses bexee's data access objects to do this. This is omitted in the opposite illustration for the sake of simplicity.
Deploying a new BPEL process to the bexee Manager means making it persistent, while deploying a new Web Service to Axis means changing Axis' engine configuration.
Per default the Axis engine configuration that holds all the necessary data
about deployed services will be stored in the web
applications WEB-INF directory as a file called bexee-
config.wsdd file.
New BPEL processes will be deployed as Web Services into Axis at run- time. This means that as soon as the Manager has finished deploying a new BPEL process, it will be immediately appear as a new Web Service and thus be available for clients to use.
