Cars Online Part 2 - Common Object Model.

Following on from my introduction to Cars Online this blog entry will take you through the development of the Common Object Model used within the Cars application and explain why it was developed and how it is used. In addition I will look into the key advantages of using this strategy and how it can be used to simplify mappings within your BPEL Processes. Although their are many possible strategies for developing Common Object Models and the concept is, most definitely, not new the one used within Cars Online is based on a number of years experience and tuning and combines full flexibility with a slight amount of, in Relational Database Speak, de-normalisation.

In addition to the discussion on the Common Object Model I will briefly specify the chosen Cars Online naming convention.

<script type="text/javascript">$(document).ready(function(){ $("#traildiv").load("../resource/cars-online/CarsOnlineTrail.html"); }); </script>


Within the pre-sales group, along with input from professional services and FAST, a simple Business Service Interface Model has been developed. Now this should not be considered the definitive answer because that is not possible given that each and every company has its own requirements. Rather the solution presented here and implemented within the Cars Online demonstration should be considered as an example of the flexibility provided by such a solution and modified according to your requirements.

Common Object Models have but used for many years and provide a simple consistent interface to all processes throughout an Enterprise. In the past these were typically based around delimited formats, EDIFACT, HL7, etc but with the advancement of XML have tended to be more verbose XML structures and this has hence rippled forward into our WSDL structures. Now although the current W3C recommendation suggest that we start building Message Only WSDL files that define Common Messages that can be used across multiple Operations we will not be taking this approach. Instead we will do some de-normalisation and define a series of Common Message XML Complex Types that will be used in each of the Messages defined within a WSDL. The reason for this de-normalisation is purely based on the implementation solution and usage requirements of some of the Binding Components.

The net result is a Business Service Interface with the following structure.

Here we can see that the Messages Contain a single part that is defined as being of a type define within an imported xsd. The result is a simple interface that will allow high level  mapping within BPEL Processes.


The key goals for the BSI Model are as follows:

  1. Clearly define the ownership and governance within a SOA Project.
    1. Business focused staff : Business Unit Managers, Business Analysts, Data Analysts, Solution Architects, etc
    2. Technical Staff : Service Implementers, Operations, Developers, S etc
  2. Support common Business / IT Language.
    1. Business Objects.
    2. Business Services.
    3. Business Service Interface.
    4. Business Processes.
  3. Allow for simple change.
    1. Data Model change.
    2. Service & Process change.
    3. Application, Systems and Network change.

BSIModel Structure

BSI ModelThe Business Service Interface Model (BSIModel) has been developed as a simple NetBeans BPEL Module, because their is no specific simple storage project, that contains no critical BPEL Processes and will never be deployed. The advantages of implementing it in this way is that the components can be referenced from you implementation BPEL Modules and can be backed by you standard Source Code Control System (CVS, SubVersion, etc). Because the contents are not copied and used directly, but referenced, any changes to the source project will be rippled through to the project that use them and hence the changes can be seen quickly and easily within your BPEL Structure.

Note: When changing the structure the referencing projects should also be open.

The BSI Model is split in the three sections:

  • BSInterfaces - Business Definition of the Interfaces
  • BusinessObjects - Core definition of the data used
  • CommonObjects - Definitions of the Common interface objects.

Essentially these sub-sections will be controlled / understood by different types of people within the organisation.

Business Objects

The Business Objects define the common objects that will be used throughout your applications and in our examples it can be seen that we have created a number xsd's that represent the data that will be used within the Cars Online demonstration. It can be seen, from the image, that we have created standard AddressComplexType, defined in the Address.xsd, and although this is not used directly within any Interface definitions rather it is referenced within other Business Objects such as the CustomerComplexType and CompanyComplexType. As can be seen these definitions are built up of aggregations of the common structures.



The example above shows the standard integration of the AddressComplexType within the Customer information. For orders etc it may be the case htat the same complex type is used multiple time (Invoice Address and Delivery Address).

In general the Business Objects will be owned, designed and built by the Business and Data Analysts.

Business Service Interface

The Business Service interface defines an Abstract WSDL containing the required operation and we have defined a standard CRUD interface (Create, Read, Update, Delete). These expose the business objects and operations to define the interface. These use a Common Message Envelope and Fault message structure defined within the Common Objects folder. The BsOrder.wsdl below shows how we have defined a single Request / Response / Fault structure and these are used by all the CRUD Operations.

Their may be situations where specific end systems require their own, none CRUD, methods and rather than pollute the Abstract BSI wsdl these can be build within a separate wsdl and use the exist Common Object Structures.

Common Objects

The Common Message Objects are based around a Common Message Envelope Style which contains the following Components:

  • Header
  • Properties
  • Data
  • Payload

The objects defined within the attached project have again been de-normalised from a purely abstract implementation and we have defined one for each type of common object. In a purely Abstract  / Generic solution we would not use the Data Element, which contain specific types, but would instead use the payload element that is simply defined as an xsd:anyType and unmarshall the contents as appropriate.

Message Envelope

Abstract Message Envelope

Order Com

Order Common Message Envelope

The above image shows the contents of the Order Common Message Envelope that the Cars Online Demonstration uses to pass order information around the system. I will briefly summarise the contents of each of its elements.



The EnvelopeHeaderComplexType contains a set of information we have chosen to pass around the system for all message and in the case of the Cars Online demonstration these include our own unique message id  the bpelid of the process being initiated (This bpelid will become significant within later blog entries as I show how it can be used with the BPEL Monitor to present an order tracking process to the client). In addition to that we have added a number of place holders to for commonly required information for message recognition and tracking.


The EnvelopePayloadComplexType simply contains a element that is defined as an xsd:anyType the idea is that I can place any XML content within this element and not need to worry that the xml structures match exactly. This could be used across all interface but we have chosen not to or simple implemented in the case of a generic error handling process which can take the payload and processes based on information contained with the header that would define the content.


The EnvelopePropertiesComplexType contains a repeating list of Name / Value pairs (PropertyComplexType) and allows the user to write an arbitrary set of additional data. This therefore give the user additional flexibility to add specific custom information that may be required for a single business process without polluting the common structure although this element should be used with care.


The Data section is where we will be placing the de-normalised specific business objects, such as the Order above, these can then be directly accessed within the BPEL Processes without the need to execute further unmarshalling of the payload. We have chosen to do this because Business Services we will be providing are distinct and process single Common Object types.


In addition to the Standard Components of the Message Envelope we have define a standard Fault Structure that will be used for all the Business Service Interface Operations although the structure is common because of the name spaces we will have multiple Fault (Exception) types. In addition to the simple Code, Status, Message elements the structure we have defined contains a recursive element (CausedBy) that allows us to track back to the source fault.


Business Service Version Management

Because the structure allows the designers to quickly ripple changes through the objects and processes we need to consider how we are going to control these changes. On a technical level this will be managed by the users Version Control system using tagging / branching etc but we will need to take into account the types of changes that may occur.

  1. Additional Elements : If additional elements are required for a structure the simplest way to implement this will be to add them the structure as optional element. This implementation will then allow any processes / third party application that do not know about these changes to continue passing in information.
  2. Element Removal : If elements are not longer need then the simplest solution is to set these as option and then the will be ignored.
If we need to implement a significant change to the structure of the data then we will need to consider how this is going to affect all processes and external system that use the Business Services and hence we will need to release a new version of the processes that are defined by the BSI WSDLs. We have chosen to manage this level of version control through the namespace attribute within the wsdl and xsd files. You will notice from the examples that all the namespace definition contain a numerical value, 1.0, and this is the major version of the file. If and when the Structure changes significantly this will be changed and the processes rebuilt to recognise the change in the namespace.

Naming Convention

The following naming convention will be used throughout future blog entries and consist of simple 2 or 3 letter prefixes.

  • bs - Business Services : Reusable BPEL based business functionality.
  • bp - Business Processes : Top level Business functionality that will use one or many Business Services.
  • pl - Partner Link with a BPEL Process.
  • bsi - Business Service Interface (WSDL).


Post a Comment:
Comments are closed for this entry.

As a member of the Oracle A-Team we specialise in enabling and supporting the Oracle Fusion Middleware communities.


« July 2016