We have published a repository for storing business processes and associated metadata. The BPEL Repository is an Eclipse plug-in originally built for BPEL business processes and other related XML data. It provides a framework for storing, ¯nding and using these documents. Other research prototypes can reuse these features and build on top of it. The repository can easily be extended with new types of XML documents. It provides a Java API for manipulating the XML ¯les as Java objects hiding the serialization and de-serialization from a user. This has the advantage that the user can manipulate the data as more convenient Java objects, although the data is stored as XML ¯les compliant with the standard XML schemas. The data can be queried as Java objects using an object-oriented query language, namely the Object Constraint Language (OCL). Moreover, the °exible design allows the OCL query engine to be replaced with another engine based on other query language.
Interoperability based on several XML standards is one of the corner stones
of Web services. The Business Process Execution Language for Web Services
(BPEL) [
XML data is commonly used by di®erent applications. However, currently managing the documents and searching information from their contents is laborious and ine±cient. It is bene¯cial to store the data in a repository that takes care of data access and executes queries. Although it is important for interoperability to exchange data in XML format across organizations and systems, it is often more convenient for a developer to manipulate the data as Java objects, instead of XML. Our goal was to build a business process repository that stores data as documents compliant to the XML standards, but allows applications to be implemented directly on the Java representation of the data model.
We have implemented the BPEL Repository, which is an Eclipse plug-in built to store business processes together with other XML data. It provides a framework for storing, ¯nding and using these documents. Other research prototypes can reuse these features and build on top of it. The repository can easily be extended with additional XML schemas because of its °exible architecture. By default it supports the common Web service standards, such as BPEL, WSDL and XML schema, and it can easily be extended to support other XML schemas for business processes and other data.
The object-oriented approach frees developers from the burden of the
underlying XML data model and allows them to concentrate on the object model of
their application, which they usually know well. The Eclipse Modeling
Framework (EMF) [
In contrast to our ¯le system based solution, there are other business process
repositories [
The BPEL Repository was recently published in IBM alphaWorks [
The architecture of the BPEL Repository is presented in Figure 1. All components are plug-ins on the Eclipse platform. The core component of the solution is the Repository API, which provides an application programming interface for external software to build on.
The Repository User Interface (UI) is an example implementation that uses the Repository API. However, it is also a useful graphical user interface to manage the contents of the repository. The user interface is integrated in the Eclipse workbench and built on the Standard Widget Toolkit (SWT) and JFace libraries.
The Data Handler is a sub-component that takes care of the data access on a ¯le system. It abstracts the choice of the storage medium from the other ) ' ' *
!" ! #
components. The data access component could be replaced with another one
storing data in a database by using a technology such as the Service Data Objects
[
In the repository, data is represented as EMF objects. Therefore, all data must
have an EMF model. However, the EMF model can be automatically generated
from an XML schema, a UML class diagram or Java classes [
The components providing EMF models for the repository are shown on the left-hand side of the Repository API in Figure 1. The Default EMF Extensions plug-in contains EMF models for BPEL, WSDL and XML schema standards. Thus, the repository supports the respective ¯le types by default. This component can be replaced by another component supporting a di®erent version of these standards or completely di®erent ¯le types. Because the Eclipse plug-in mechanism is used, this does not require any modi¯cations in the other parts of the repository.
Similarly, other EMF extensions can be plugged into the repository. In the evolving research community, extensibility is an asset. For instance, in the context of combining business process management with semantic Web, the repository can easily be extended to support a new document type containing metadata related to a business process.
The Sample EMF Extension contains an EMF model that is used in the user
guide [
First, the data structure can be modeled as a UML class diagram, which is usually much faster than describing the same structure as an XML schema. Next, the UML class diagram is transformed to an EMF model. An editor can be automatically generated for the EMF model. An XML schema can be generated from the EMF model, if desired. In any case, instances of an EMF model can be serialized to interoperable XML ¯les. Instances of the model can be generated for testing purposes with the editor, which takes care of proper syntax. Finally, the EMF model is plugged into the repository, which persists the data and provides capabilities for querying data. A chief advantage is that queries can be formulated using the same object-oriented model as was used to create the data structure in the ¯rst place. Thus, the XML representation is used only for interoperability with other systems, and the developers need not bother with the concrete XML syntax. 2.2
We used existing query engines with the repository. The repository handles the iteration over the queried objects, but each sub-query is executed in the query engine plugged into to the repository. It is possible to change the query engine to another pre-registered one between queries. The available query engines are shown on the right-hand side of the Repository API in Figure 1. The repository has been tested with two OCL query engines, that query Java objects with an object-oriented query language, namely OCL.
If the repository is installed on top of the IBM Rational Software Architect (RSA) product, the OCL engine of the latter can be used. However, as we did not want to limit the repository to a single commercial query engine or a speci¯c query language, the query engine interface has been built generic. Therefore, the IBM OCL engine is plugged into the repository using an adapter. The IBM OCL Engine Adapter is delivered together with the repository.
Another OCL engine was built at the University of Kent [
It is straightforward to plug a new query engine into the repository or adapt
an existing query engine for it. An example of how to adapt an OCL engine
is included in the user guide [
The repository is not aware of the query language that is used. The repository merely passes the query and other parameters from the user interface or external software to the query engine selected together with the EMF object that is to be queried. Thus, any query engine that can execute queries on EMF objects can be plugged into the repository.
One limitation of the query mechanism is that the performance is only linear
compared with the number of documents that are queried. Indexing data or other
ways to improve the query performance are not used. However, this performance
has been su±cient for research prototypes. For example, querying 100 BPEL ¯les
took 3 seconds on a laptop in our performance tests [
The data is organized in a tree of organizations. The organizations are mapped to directories in a ¯le system. Each organization may contain a business process and associated metadata grouping the related ¯les together. In addition to these data documents, a descriptor document is stored in each organization. It contains the ¯le type and the role of each data document in the organization. This information is used to make the conversion between EMF objects and XML ¯les. In addition, the role describes how the data document is related to the other documents in the organization. For instance, a WSDL ¯le stored with the repository may contain the public interface or the partner links of the BPEL business process.
Queries can be applied to ¯les with a speci¯ed role in an organization, a list of organizations, or a list of sub-trees in the organization hierarchy. Related ¯les can be searched based on their roles.
Data can be accessed from the ¯le system as XML ¯les and through the repository as EMF objects. Any directory in a ¯le system can act as the root organization of the repository contents. The data in the repository can be moved to another location or a computer as simply as copying the directories. 2.4
The repository has been deployed with a change management system called
CHAMPS. As part of the solution, planning algorithms are used to facilitate
the automatization of the change and con¯guration management. The plans
are stored as BPEL ¯les into the BPEL Repository. In addition, the plans are
analyzed and the results are stored as metadata associated to the plans. The
metadata includes information about the plan such as its number of activities,
degree of concurrency, execution duration and correctness [
Storing the analysis results as metadata enables reuse of the data, and unnecessary recomputing of the results can be avoided. The suitable plans are found from the repository by querying the content of the plans and their associated metadata. For example, the plans that are structurally correct can be found by querying the metadata. Among these plans the ones that reach a speci¯ed goal can be found with a subsequent query.
During the development of the system, trying out di®erent alternatives of the metadata schema was uncomplicated, since the data structure was designed as a UML class diagram and the corresponding EMF classes were used as the basis of the implementation and the OCL queries. The developers were able to avoid completely working with the XML representation of the data, because it was automatically generated and used only as the serialization format behind the scenes. 3
The repository has already been proved useful for IBM internal research
prototypes [
As next steps, we plan to contribute our experiences gained while building
the repository to the IP-SUPER project [