Package Name | Comment |
bexee | |
bexee.admin |
bexee Administration package.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:10 $
|
bexee.ant |
bexee Ant Tasks.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:22 $
|
bexee.axis |
Axis integration package.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:11 $
|
bexee.core |
Core classes and interfaces of the bexee engine.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:27 $
|
bexee.dao |
Persistence package; a "Data Access Object" pattern implementation for bexee.
Last modified: $Revision: 1.3 $, $Date: 2004/12/09 08:42:20 $
|
bexee.ecs |
A package with classes for simplyfied usage of the org.apache.ecs library.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:30 $
|
bexee.event |
bexee Event package.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:16 $
|
bexee.model |
Java representation of the BPEL language.
Last modified: $Revision: 1.3 $, $Date: 2004/12/09 08:42:31 $
|
bexee.model.activity |
This package contains all interfaces representing BPEL activities as
specified in the
bpel4ws.xsd XML Schema.
While bexee provides a default implementation of those activity interfaces,
it is possible to implement Activitites using an other technique.
BPEL activities can be subdivided in two groups, atomic activities
and structured activities. Basic activities represent a functionality,
e.g. calling an external service or receiving a call. Structured activities
contain other atomic or structured activities.
Last modified: $Revision: 1.4 $, $Date: 2004/12/09 08:42:34 $
|
bexee.model.activity.impl |
This package contains default implementations
of the interfaces from the bexee.model.activity package.
Last modified: $Revision: 1.3 $, $Date: 2004/12/09 08:42:19 $
|
bexee.model.elements |
This package contains all interfaces representing BPEL elements as
specified in the
bpel4ws.xsd XML Schema.
While bexee provides a default implementation of those elements interfaces,
it is possible to implement elements using an other technique.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:23 $
|
bexee.model.elements.impl |
This package contains default implementations
of the interfaces from the bexee.model.elements package.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:37 $
|
bexee.model.expression |
This package contains all interfaces representing BPEL expressions as
specified in the
bpel4ws.xsd XML Schema.
While bexee provides a default implementation of those expressions,
it is possible to implement them using an other technique.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:18 $
|
bexee.model.expression.impl |
This package contains default implementations
of the interfaces from the bexee.model.expression package.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:08 $
|
bexee.model.process |
This package contains interface which are used in order to represent a BPEL process. You can find the BPEL process specification in this
bpel4ws.xsd XML schema.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:29 $
|
bexee.model.process.impl |
This package contains default implementations for the bexee.model.process package.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:14 $
|
bexee.model.xmltobpel |
This package contains BPEL process element and activity factories
used by the Digester.
BPEL document transformation (XML-OO mapping)
Rationale and description
A deployed BPEL document needs to be transformed in a tree structure
of objects representing a BPEL process type. Bexee will then use such
a tree structure for the execution of processes. This transformation
is a XML to OO mapping and within bexee this task is accomplished with
the Jakarta Digester tool http://jakarta.apache.org/commons/digester/.
Briefly, the Digester is configured with an xml mapping description
which describes how xml elements contained in BPEL documents will be
mapped to the correspondent BPEL activities and elements. For the
creation of activity, Digester is configured to use factories. Each
activity type has its own specialized factory. In the following
showing the usage of Digester and the creation of BPEL process types,
this mapping description is called "bpel-rules.xml".
It is possible to let Digester create the objects without using
specialized factories, but in the case of bexee it is advantageous to
use this customized technique. BPEL activities have complex properties
and it is easier to create those properties with specialized
factories. In addition, BPEL activities and elements reference other
elements, e.g. variables from the same BPEL process type. It is
therefore necessary to find other elements (variables, partner links,
etc.) and associate them with some activities in the BPEL process.
In order to be able to find other elements and activities existing
in a BPEL process type, the factories used by Digester
don't create process elements themselves, but delegate this
task to a BPELElementFactory. Such a factory exist once per BPEL
process, therefore all specialized activity and element factories used
by Digester use the same BPELElementFactory, which exists once per
BPEL process type. Every process element is registered at creation and
can thus be found once referenced in an activity at a later time of
BPEL document parsing.
Code and configuration excerpts
Following an excerpt from the Digester xml-oo mapping description "bpel-rules.xml"
"bpel-rules.xml"
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE digester-rules SYSTEM "http://bexee.sourceforge.net/dtd/digester-rules.dtd">
<digester-rules>
<!-- -->
<!-- parsing the Process -->
<!-- -->
<pattern value="process">
<factory-create-rule classname="bexee.model.xmltobpel.ProcessImplFactory"/>
<!-- -->
<!-- parsing the PartnerLinks -->
<!-- -->
<pattern value="partnerLinks">
<object-create-rule classname="bexee.model.elements.impl.PartnerLinksImpl"/>
<pattern value="partnerLink">
<factory-create-rule classname="bexee.model.xmltobpel.PartnerLinkImplFactory"/>
<set-next-rule methodname="addPartnerLink"/>
</pattern>
<set-next-rule methodname="setPartnerLinks"/>
</pattern>
<!-- -->
<!-- parsing the Variables -->
<!-- -->
<pattern value="variables">
<object-create-rule classname="bexee.model.elements.impl.VariablesImpl"/>
<pattern value="variable">
<factory-create-rule classname="bexee.model.xmltobpel.VariableImplFactory"/>
<set-next-rule methodname="addVariable"/>
</pattern>
<set-next-rule methodname="setVariables"/>
</pattern>
<set-next-rule methodname="setProcess"/>
</pattern>
<!-- -->
<!-- parsing the sequence -->
<!-- -->
<pattern value="*/sequence">
<object-create-rule classname="bexee.model.activity.impl.SequenceImpl"/>
<set-properties-rule />
<set-next-rule methodname="activity"/>
</pattern>
<!-- -->
<!-- parsing receive -->
<!-- -->
<pattern value="*/receive">
<factory-create-rule classname="bexee.model.xmltobpel.ReceiveImplFactory"/>
<set-next-rule methodname="activity"/>
</pattern>
<!-- -->
<!-- parsing invoke -->
<!-- -->
<pattern value="*/invoke">
<factory-create-rule classname="bexee.model.xmltobpel.InvokeImplFactory"/>
<set-next-rule methodname="activity"/>
</pattern>
</digester-rules>
The java code for a factory responsible for the creation of a Receive
BPEL activity:
"ReceiveImplFactory.java"
public class ReceiveImplFactory extends AbstractObjectCreationFactory {
public Object createObject(Attributes attributes) throws Exception {
BPELElementFactory elementFactory = BPELElementFactory
.getInstance((BPELProcess) getDigester().getRoot());
String partnerLink = attributes.getValue(PARTNER_LINK);
String portType = attributes.getValue(PORT_TYPE);
String operation = attributes.getValue(OPERATION);
String variable = attributes.getValue(VARIABLE);
String createInstance = attributes.getValue(CREATE_INSTANCE);
return elementFactory.createReceive(getStandardAttributes(attributes),
partnerLink, portType, operation, variable, createInstance);
}
}
As already mentioned, the activity factory only delegates the
creation of an Activity to the BPELElementFactory, following an
excerpt from this element factory:
"BPELElementFactory.java"
public class BPELElementFactory {
...
...
...
private Map variables = new Hashtable();
public Variable createVariable(String name, String messageType,
String type, String element) {
Variable variable = new VariableImpl();
variable.setName(name);
variable.setMessageType(expandToQName(messageType));
variable.setType(expandToQName(type));
variable.setElement(expandToQName(element));
variables.put(name, variable);
return variable;
}
public Object createReceive(StandardAttributes standardAttributes,
String partnerLinkName, String portTypeString, String operation,
String variableName, String createInstance) {
PartnerLink partnerLink = retrievePartnerLink(partnerLinkName);
QName portType = expandToQName(portTypeString);
Variable variable = retrieveVariable(variableName);
Receive receive = new ReceiveImpl(standardAttributes, partnerLink,
portType, operation, variable, createInstance);
return receive;
}
public Variable retrieveVariable(String variableName) {
if (StringUtils.isNullOrEmpty(variableName)) {
return null;
}
return (Variable) variables.get(variableName);
}
...
...
...
Pawel Kowalski
Last modified: $Revision: 1.2 $, $Date: 2004/11/18 14:08:21 $
|
bexee.util |
bexee common utility classes.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:36 $
|
bexee.web |
bexee web interface package.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:24 $
|
bexee.wsdl |
bexee WSDL extensions.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:34 $
|
bexee.wsdl.extensions.partnerlinktype |
BPEL PartnerLinkType WSDL extension.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:33 $
|
bexee.wsdl.extensions.partnerlinktype.impl |
BPEL PartnerLinkType WSDL extension default implementation.
Last modified: $Revision: 1.2 $, $Date: 2004/12/09 08:42:21 $
|
net.sourceforge.bexee.Travel | |