Software in SCA (Service Component Architecture) implements Services. As shown in the diagram below, a service is presented with a request. The service then performs process steps to create a response. The process steps may query the repository or update the contents of the repository. The process steps may also invoke other services of another actor. An invoked service may be in the same theater or a different one.
Currently, the Otter Server supports the process languages of Java and BPEL. Others could be added.
Java Software
A component written in the Java programming language is structured as a class. The component services are the public functions that satisfy the signature of a service. When the class is loaded, the “init” function is called by the Otter Server to pass the script control information.
Each service has the same signature:
DataGraph ServiceName (DataGraph request, DataGraph response)
The DataGraphs are defined by the Service Data Object reference model.
Control information provided to the “init” function provides the services with access to query/update the repository of named objects, and to invoke other services. Only the domains authorized by the component’s definition may be accessed. Also, only the service links defined by the component may be accessed.
The request, DataGraph, is what the requestor knows. It contains the structure, the metadata (logic graph), and the data (named objects). The response DataGraph only contains metadata. It is the logic graph of what the requestor wants to know.
The process completes by returning a DataGraph to the requestor. This DataGraph contains the response metadata and the data determined by the service.
BPEL Software
Software may also be written in BPEL (Business Process Execution Language). This language as implemented in the OtterServer is describe int the book, The OWL and the Architect, in Appendix B. Here is an extract that describes the BPELlike ontology applied by the OtterServer to emulate BPEL processes:
BPELlike is an OWL ontology applied by OTTER to provide business process execution. BPELlike is based upon the standard language BPEL (Business Process Execution Language). The figure below is a Cord diagram showing all domain classes and relationships in the BPELlike ontology.
The BPELlike ontology contains activities linked together in the order they are to be executed. These activities are OWL individuals defined by the Activity class. The BlockActivity class defines OWL individuals containing activities linked together. An individual of class BlockActivity may include one or more sets of linked activities.
Most block activity classes inherit from both the Activity class and the BlockActivity class. Although there are some activities that only inherit from the BlockActivity class or the Activity class.
The following is a list of all the process classes defined in BPELlike:
- OnRequestBlock – The service entry to a process.
- CatchAllBlock – Activities to catch and process all exceptions.
- CatchFaultBlock – Activities to catch and process specific exceptions.
- InvokeBlock – Activities to prepare for and to make a reference to an external service.
- UpdateBlock – Activities to access, update, and store individuals into an ontology.
- WhileBlock – Repeats activities until a specific condition is met.
- PickBlock – Starts multiple sub-processes simultaneously and completes when the first sub-process completes.
- FlowBlock – Starts multiple activities to execute in parallel.
- IfBlock – Selects the direction of process flow based upon a condition.
- VariableActivity – Creates a variable.
- DataGraphActivity – Creates a datagraph.
- AssignActivity – Provides for assigning values to variables and datagraphs.
- WaitActivity – Causes the process to wait a specified amount of time.
- ThrowFaultActivity – Throws a specific fault.
- Terminate – Ends the process.
Each of these process activities are described in separate sections.
Explanation Through Visualization
Since the book was published, the visualization of a component defined in BPEL has been added. Now, all fifteen activities are visible as process graphs. Blocks are drawn with a light blue box around the block and with a “+” symbol in the upper left hand corner. When the plus is selected, the subgraph of the block is shown and the block then has a “-” in the upper left hand corner.
Here are some examples:
Example 1
In this first example, the “DataGraph” activity defines a DataGraph and populates it with a query to the repository. It also shows a “parallel process” block open to show two paths to run in parallel.
Example 2
In this example, the “pick” block is shown which is similar to the parallel block. In addition, two different forms of the “if” are shown. The first “if” shows two paths that the logic may follow for either true or false. In the second and third there is only a true path.
Example 3
The expanded “invoke” block shows subgraphs for handling exceptions, a subgraph for preparing the request, and a subgraph for processing the response.
Example 4
The “update” block queries the repository and the activities within the block apply updates to the Service Data Object retrieved. Also, note that this example is in different colors than the other examples. There are twenty-six color combinations available to select from.
The ability to expand and collapse blocks provides a top-down explanation of the process blocks.
The BPEL emulator is defined as a Java class operating as described above. In the same manner, Java can be applied to provide support for other process languages. Other languages could be emulated or compiled and executed. The structure provided by SCA and SCO makes it possible to support services as neural networks or even to access quantum computers.