STP/IM Component/Sample scenario involving the intermediate meta-model

Introduction

This page presents a possible scenario for creating a sample SOA architecture using several Eclipse STP editors. The scenario greatly simplifies the description of each step in order to keep the presentation focused on the representation of artefacts in the internal meta-model. In addition, the representation of the resulting internal model is kept to a minimum, ignoring some elements of the meta-model completely for the purpose of reducing visual clutter. Some of the elements that are ignored are:

• Owner
• Transition
• TransitionUnderCondition
• ObservableAttribute

Each of the following steps in creating the architecture for a [highly original] sample travel service involves the usage of an editor. Each section of this page shows one such step, highlighting the simplified output of the editor as well as the resulting intermediate model.

Defining a basic process

Using a "process editor" such as a BPMN or BPEL editor, the business analyst defines a simple travel agency scenario, reserving a hotel. The reservation process involves booking a room, obtaining the weather forecast for the trip dates and sending a confirmation email to the customer.

The "process editor" saves the representation of its diagram into the intermediate model. The model now contains the following instances:

Opening the SCA Editor

In order to start defining the architecture for the travel reservation system, the architect opens up the STP's own SCA Editor. Since the editor is linked with the internal model, it provides an automatic "import" of its elements and creates empty placeholders for services corresponding to the identified processes. This placeholders would later be refined to either implement the required services or to link to external services.

Since the intermediate model contains one process, the SCA Editor interprets this as a request for an orchestration service and creates one. It is this newly created orchestration service that will provide the process functionality. The services involved in the orchestration are placed inside a generated composite that will expose the process service's interface. The figure below shows a rendering of the composite.

The generated placeholders are BookHotel_Provider, GetForecast_Provider and SendEmail_Provider, corresponding to each process step. Only the BookHotel_Provider will be replaced with an actual service created with STP, as seen in the next section. The updated intermediate model now contains the following elements, corresponding to the current architecture:

The generated Service Class, "Reservation Services" will contain all the generated placeholder services as well as the orchestration service "Travel Service". The intermediate model will also contain the appropriate service dependencies (represented by dotted lines), as corresponding to the self-reference of the Service element in the intermediate meta-model. In this sample scenario, the dependencies correspond to the SCA dependencies between the orchestration service and the execution services (the wires between the references and services on the SCA diagram).

Completing the SCA Architecture

The architect knows that there exist services to fulfil the hotel booking, weather forecast and email services operations required by the reservation system. However, he/she decides to create a wrapper component for the external hotel reservation service implemented as a POJO or as an annotated Java class using the Service Creation component of Eclipse STP. For the other services, the necessary wiring is done such that the orchestration can perform its function. The actual bindings for each service are not shown in the diagram, they will be presented in the next section. With the new architecture in place, the SCA diagram looks as below.

The updated intermediate model now contains the wrapper service as well as the introduced dependency from the wrapper to the actual service. File:Added-services.png

Moving to a JBI Runtime

The system deployer decides that a JBI-compliant ESB would provide a good platform for the resulted system and decides to open-up a JBI-specific editor in Eclipse STP. Note that an SCA runtime could have been chosen as the execution platform, in which case the diagram in the previous section would have been directly used to generate the deployable artefacts. Moving to a JBI runtime requires the definition of service units and their deployment onto appropriate binding components and service engines. Based on the intermediate model augmented with binding definitions from the previous step (not shown in the previous SCA diagram nor in the model), the JBI editor is able to automatically present a potential infrastructure configuration, as below.

The bindings could have also easily been defined in the JBI editor itself by placing each service in the appropriate JBI component (BC or SE).

This looks pretty good to the deployer, so after configuring the final parameters, a JBI assembly containing all the artefacts (yellow boxes in the JBI diagram) the architecture is deployed to a JBI runtime of choice.