img > Issue LXVII, October 2012 > Flexible Service Repository Taxonomy's Realization
Sergey Popov

Sergey Popov


Sergey Popov is a Senior Technical Manager and SOA Architect at Liberty Global, the second biggest cable and telecommunication provider in Europe. He is currently responsible for the implementation of a Pan-European service layer for the entire enterprise. He has broad technical experience with SOA and application integration architecture development, and specializes with integration development based on Oracle applications. During his 15 years of working in the shipping and transportation industry, he helped with establishing communications and message brokering platforms for the world's biggest RO-RO and container shipping companies. In several projects for business critical applications within enterprises Sergey designed and implemented ESB solutions with average transaction volumes of over 100,00 messages per day. Sergey's wide business knowledge in the Telecom industry is further complemented with expertise in the SCM, ERP, banking and finance sectors. Sergey is SOA Certified Architect, SOA Certified Security Specialist, and a SOA Certified Trainer, and is further an Oracle Certified professional and Oracle Fusion Middleware architect.


rss  subscribe to this author


Flexible Service Repository Taxonomy's Realization

Published: October 18th, 2012 • Service Technology Magazine Issue LXVII PDF

Abstract: This article is dedicated to the taxonomy of the Service Repository and the various ways it is used by the lightweight Service Broker for dynamic Service Compositions. The first article that was published earlier in August discussed the entities and service attributes that required looking up from different layers of service frameworks (Orchestration, Service Composition and Adapter services). Here we will examine relations between entities in repository, suitability for DB implementation and how they can be presented in the XML Message Container, which is sufficiently universal for the agnostic Service Broker.

As mentioned earlier, this practical approach bears many similarities to the more theoretical Service-Aware Interoperability Framework-Canonical Definition (SAIF CD), recently published by HL7. This approach of practical realization was presented in September at the 5th International SOA, Cloud and Service Technology Symposium. Interestingly, this topic appeared to be quite popular as OASIS, one of the open SOA standardization communities, also decided to present on the draft version of "Reference Architecture Framework for SOA" [REF-1]. Their draft seemed quite theoretical in its mention of how its committee members were still debating on the definition of "service." When asked about the practical value of this reference model for SOA practitioners, Mr. Brown said that the purpose is "to build a better SOA." This article will employ the definition of "service" as provided by Thomas Erl and focus on the practical realization of the taxonomy of Service [REF-2].

Entity Model

We start by examining the basic artifacts, most of which were already identified when the lookup entities were counted. Everything begins with the Object, which is the most abstract entity in any hierarchy. There is quite a limited number of truly unique things on the enterprise level that are usually described during the earlier stages of a project’s MDA exercises (in UML form).

The transportable—or serializable—form of the Object is a Message, which is slightly less abstract but can still exist as a message “Message,” commonly described as XSD. The Object does not exist alone; the Object and its context live and evolve within the application, presented as a set of components and resources that are interfaced by the API (or contract) composing a complex artifact—called a Trading Partner in old EDI times. Not exactly a SOA term, it is still capable of describing an Application, application user(s), API (contract) with related protocol(s) and interchange pattern(s) as one composite entity.

A Message, representing the application Object, is constructed and propagated when the noticeable change in the Object's state occurs, which denotes the Events. These Events can be specific to this application (a “basic” or “primitive” event), or, taken into a broader SOA context, can be an enterprise business Event. Event filtering and recognition, and Message construction and mediating, are usually controlled by a set of Rules. These Rules play a very significant role in every aspect of Service Service activity and composition policies. When combined together in a certain order, they represent rulesets. Services are the essence of SOA, and through them models and realizations assume different roles in every framework of the SOA landscape.

For the purposes of collecting for this entity’s taxonomy, the Service/Task is the executable module with a clearly identified API (separate for WS and implanted for components) and service engine responsible for execution. In this case, the term "executable" means that every service or component must support dynamic execution or invocation in the appropriate form—Web Services must be composable (via supporting standardized service contract, statelessness and loose coupling), Java components should support IoC/Dependency Injection, PL/SQL packages written to support NDS, etc. The last common abstract thing is a Process as Composition of previously registered Services/Tasks.

Following the basic rule of separation of abstract and concrete taxonomy parts (as we have it in a standard WSDL), we can initially assume that all seven entities are abstract with some exception for the following properties:


Table 1

The abstract entities' hierarchy can be shaped as follows, with the primary artifacts in white:


Figure 1

To finalize practical implementation of this semantic, we will examine all of the entities and identify all of the properties essential for dynamic Service Compositions. Furthermore, we will define how these properties are implemented in the message structure that is utilized by the Service Broker.


The Object is related to the Entity, Business or Service. In its serialized form, the Object presents the Message business payload. The number of enterprise business Objects is always quite limited: Product, Resource, Customer, etc. Information about transporting the Object is one of the mandatory parts of message identification, used for object filtering, routing and transformation (should be avoided). This information must be presented in the Message Header, together with the Object Context, for Events identification and State Messaging pattern [REF-3] realization.


Figure 2


The Service/Task is the most trivial part of the taxonomy and is entirely defined in SOA terms. An executable module is registered that can be part of Composition—to fulfill the role of the Composition member—and/or something that can be dynamically executed—for instance, Rule function. Thus, the Role cannot be a property of the Service as it is related to the Service within the Composition. The Engine and the Model are Service properties. Part of the designtime service definition is the registration of service event messages, provided to the runtime log. This information is used for runtime audit and testing purposes. Services can be part of a bigger composition (SCA), which is also a Service, and can be registered in the repository for further reuse.


Figure 3


Services Composition is the objective. A simple and descriptive representation of the Service Composition is the main goal of the Service Repository’s taxonomy and the foundation for the Service Broker. Process as a Service Composition is therefore a sequenced collection of Services, performing the Operations and assuming the Roles in order to fulfill the complex business logic of transporting—with possible transformation—the Object in the form of a Message between Applications-Composition members, presented via public Endpoints (contract, interfaces), initiated by the business Event and finally occurring in the Composition Initiator.


Figure 4

This statement essentially formalizes the XML entity that will henceforth be denoted as the composition Execution Plan (EP).

From this description of the Execution Plan, it is clear that the names of the three entities as an input are necessary for its discovery:

  • Object
  • Event
  • Service-Composition initiator


Rules are governing conditions used to control all of the common aspects of service activities. Rules Centralization is one of the core SOA patterns used to establish Service Repository in general. Rules are special, however, as rule storage realization is dependent on the Rule Engine in particular. The Rule Engine(RE) is a special form of Service Engine with very high performance demands; these demands are usually accommodated by placing the rule storage as close to the engine as possible. The most obvious Repository’s realization is on DB; thus, we should be aware of possible DB rule storages from various vendors [REF-6]. Oracle from DB version 10g has a rule management package DBMS_RLMGR with extensive functionality.

However, this doesn’t mean that the Rule Engine realization will also be on DB—avoiding vendor lock-in is not always of primary concern. The main problem is the visibility of defined rules, so the rules’ names that reference from the Repository to the actual rule storage must be provided. The rule reference in the Service Repository leads to the actual ruleset in RE storage, and therefore is part of the designtime rule centralization exercises.


Figure 5

In one possible scenario, the Inventory Endpoint, using the Message Header’s input parameters described above, will recognize the decision table’s name and route the Object to this table for Rule Evaluation. RE can be used to find XML EP by name during runtime if the EP storage is file based, but that is not preferred.

Interestingly, the requirement to store rulers (rulesets) close to the RE can also be fulfilled from the other direction by moving the RE towards the storage. Depending on the actual complexity of your Business rules, it would not be too difficult to implement a lightweight but effective custom Rule Engine, if open source engines (Drools for JBoss [REF-7]) are not an option for infrastructural reasons.

Describe the supported rule types: XPath and Functional

  1. ) XPath-based rules will evaluate the XML object using single java getNodeValue() or XDK function valueOf(xmlDoc, xpathRule), where the Rule is the XPath expression (xpathRule)
  2. Functional rule realization is based on Dependency Injection, where the rule predefined function is executed dynamically for object data evaluation. The returned value is compared with data stored in the decision table
  3. Define acceptable rule operations and implement corresponding handlers (=;>;<;!=, etc.)
  4. Define supported rule aggregations (weak and strong: AND; OR) and implement the aggregation handler accordingly

Implementation of Rule Centralization clearly does not require the presence of the single Rule Engine—only the ruleset’s storage needs to be common (and preferably SR-based). Judging from the step listed above, it is probable and at times desirable to implement RE in several key points of infrastructure—in the ESB layer for rule-based routing and invocation, and in DB for functional audit and KPI evaluation. The last piece relating to the operational policy and its monitoring rules are essential. Policy entity will consequently be placed close to the rules definitions.

Implementation of the Event’s taxonomy is also straightforward—the Event is the change of the Object’s state; the Object exists within the application (service or composition) and, from the entire enterprise application perspective, the Event can be seen as either primitive (basic) or enterprise (complex). Events filtering and recognition is a task for the Rule Engine, usually inside the northbound adapter layer. The Event is part of the Message Header structure, together with three other mandatory elements, and is the key part of composition coordination and context management. The biggest part of this management is apprehended by the Message elements.



Figure 6

A Business Message is a serialized Business Object. In regards to Service Brokering, it is presented as an Enterprise Business Object (EBO) XSD in the CDM stack. This is an actual payload, but it is necessary to define and implement other essential parts of Message Container in order to achieve agnostic Service Brokering. Two of them have already been mentioned: Message Header (MH) and Compositions Execution Plan (EP). The other possible moving parts of the Message Container are illustrated in the diagram on the right.

The Message Header is a SBDH compliant construct [REF-9] whose main purpose is to convey additional metadata about the message or about a payload document in the message. Originally from its specification, it can also provide generic processing information.

In order to support the Object Referencing part and Process Coordination part, we propose separating the processing construct into the Process Header, which will contain the composition EP as coordination instructions for the Service Broker.

The Business Object (EBO), Message Header and Qualified Data Types (QDT) are subject to versioning and should have namespace postfixes as per the individual current versions.

In addition to the QDTs, the Qualified Data Object (QDO) can be maintained and governed. Governing should assume control of the distinction between QDT and QDO, for example: QDT: Credit Card Data Type, Local Timestamp, Local Date, Specific ID, QDO: Address, etc.

Note: Qualified types and Objects can also be part of payload (EBO).

In a message container, EBO will be presented as <any>

<xsd:element name="Payload">
       <xsd:any processContents="lax"/>

however, as long as SB is being built on the EBF layer, the primary concern is the ability to perform message/Service Brokering agnostically. The adapter framework, together with the service perimeter guard, is responsible for message screening, validation and wrapping the ABO/EBO into the container.

Thus, the Application or Service acting as a composition initiator (the most common role of Trading Partner-Sender) is not required to construct the message container; it can be done by adapters in the ABCS layer, although all of the necessary elements must be present in the Message Header:

  1. Transactional data, with in-timestamps, object ID, object primary key name and key data. Basic event identification also needs to be provided in a way that is visible to the application-sender. This will be used for object identification in the agnostic message container.
  2. To identify complex business events and any associated Service Compositions, information that is solely about the Object is not enough. The Object exists in an operational environment in conjunction with other objects and in transit from one state to another. This information should be presented in the message header as name/value pairs.


Figure 7

XML Implementation of Execution Plan

Finally, the Execution Plan, also known as the Task List or Service Routing Slip, is the XML representation of the Service Composition described earlier. It is a sequence of the tasks with endpoint URLs, where a task could have steps for synchronous MEPs and a definition for Service Engines, which are responsible for task execution (see example below: Oracle OSB).

As the example demonstrates, the list of the actual task's operation is rather limited: invoke and transform. This minimal set for Service Broker functionality is sufficient since there are no plans to create another BPEL. For error handling, task pairs can have rollback or a compensation part, which will be executed by the Service Broker if the response from the first execution is negative.

In general, compensation can be another execution plan, if the rollback scenario is complex. The rule of thumb is simple: rollback tasks can be implemented in the same execution plan. Complex compensation activities can be combined in a separate execution plan and the Master Service Broker delegates execution to the sub-controller (another instance of the Service Broker). These operations are controlled by the error handler, which also communicates with the Service Repository in order to find the errors resolution. It is worth mentioning that the Execution Plans are part of the Message Process Header in the message container.

Physical implementation of the execution plan below done by TMNS [REF-7]:


Figure 8

<?xml version = '1.0' encoding = 'UTF-8'?>
<phs:ExecutionPlan xmlns:phs="urn:com:telco:lgi:pe:processheader:v01">
     <phs:invoke taskDomain="OrderFulfillment" taskName="changeStatus" 
        <phs:taskSteps flow="request" technology="OSB">
         <phs:transform location="OF/Xquery/transformation/
	 ChangeOrderRequest" type="OSB-Resource"/>
         <phs:invoke protocol="HTTP" endpoint="http://
        <phs:taskSteps flow="response" technology="OSB">
         <phs:transform location="OF/Xquery/transformation/
	 ChangeOrderResponse" type="OSB-Resource"/>

XML Implementation of Execution Plan

The Enterprise Service Repository database schema is determined to be an outcome of realization of service taxonomy, which is simplistic but fully functional and capable of supporting runtime and designtime discoverability for practically any line of business—not only Telco. Relations between entities are clearly visible and highly suitable for exposure by quick JAX-WS Service Inventory Endpoint.


Figure 9


[REF-1] Reference Architecture Framework for SOA

[REF-2] Prentice Hall Service Technology Series SOA Principles of Service Design by Thomas Erl.

[REF-3] Prentice Hall Service Technology Series SOA Design Patterns by Thomas Erl.

[REF-4] Oracle DB Rule Manager

[REF-5] The Drools Rule Engine

[REF-6] Standard Business Document Header (SBDH)

[REF-7] TMNS Service Delivery Team

[REF-8] The WS-Coordination Context Management Framework by Thomas Erl