Cars Online Part 2 - Common Object Model.
By The Old Toxophilist on Feb 05, 2010
Following on from my introduction
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,
In addition to the discussion on the Common Object Model I will
briefly specify the chosen Cars Online naming convention.
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
The key goals for the BSI Model are as follows:
- Clearly define the ownership and governance within a SOA Project.
- Business focused staff : Business Unit Managers, Business Analysts, Data Analysts, Solution Architects, etc
- Technical Staff : Service Implementers, Operations, Developers, S etc
- Support common Business / IT Language.
- Business Objects.
- Business Services.
- Business Service Interface.
- Business Processes.
- Allow for simple change.
- Data Model change.
- Service & Process change.
- Application, Systems and Network change.
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.
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
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
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
The Common Message Objects are based around a Common Message
Envelope Style which contains the following Components:
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.
Abstract Message Envelope
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
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.
- 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.
- Element Removal : If elements are not longer need then the simplest solution is to set these as option and then the will be ignored.
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).