Académique Documents
Professionnel Documents
Culture Documents
Appendix A.
ArchitectureGuide.fm
21
ArchitectureGuide.fm
Cost Savings: The flexibility of reusing software components results in both a cost and
time-saving benefit.
Business Process Alignment: SOA is built around services, which are representations of
business processes. It is one of the first times in the history of software architecture that
business processes and software components are so closely aligned, making the
technology a direct solution to a particular business goal.
Channel
B2B
IVR
Consumers
Business Process
Composition; choreography;
business state machines
Service
Consumer
Services
atomic and composite
Service
Provider
Service Components
Operational Systems
Packaged
Application
Custom
Application
OO
Application
Operational Systems
This layer includes all custom or packaged application assets in the application portfolio
running in an IT operating environment, supporting business activities.
22
ArchitectureGuide.fm
The operational layer is made up of existing application software systems; thereby, it is used
to leverage existing IT investments in implementing an SOA solution. A number of existing
software systems are part of this layer. Those systems include:
Existing custom applications, including J2EE applications (such as the Services already
developed so far)
Legacy applications (to be contacted through TCP/IP)
Existing database systems
Connection to Systems and Sites which are using non-standard protocol (no SOAP)
Service Components
This layer contains software components, each of which provide the implementation for,
realization of, or operation on a service, which is why it's called a service component.
Service components may comply with the Service Component Architecture (SCA) and
Service Data Objects (SDO) specifications.
Services
This layer consists of all the services defined within the SOA. For the purposes of this
reference architecture, a service is considered to be an abstract specification of a collection of
(one or more) business-aligned IT functions. The specification provides consumers with
sufficient detail to invoke the business functions exposed by a provider of the service; ideally
this is done in a platform-independent manner. The service specification includes a
description of the abstract functionality offered by the service similar to the abstract stage of a
Web Services Definition Language (WSDL) description.
Exposed services reside in this layer; they can be discovered and invoked or possibly
choreographed to create a composite service.
This layer contains the contracts (service descriptions) that bind the provider and consumer.
Services and their underlying building blocks are defined according to the service
identification activities like SOMA or can be based on reusable industry assets like the
Websphere Fabrics Telecom Content Pack.
Business processes
Compositions and choreographies of services exposed in layer 3 are defined in this layer.
One use service composition to combine groups of services into flows, or we choreograph
services into flows, thereby establishing applications out of services. These applications
support specific use cases and business processes. To do this, visual flow composition tools
like Websphere Business Modeler can be used for design of application flows. The figure
below shows how a business process P can be implemented using services A, B, C, and D
from the services layer. Process P contains the logic for the sequence in which the services
need to be invoked and executed. The services that are aggregated as a business process, or
flow, can be individual services or composite services made up of individual services.
23
ArchitectureGuide.fm
Consumers
The consumer layer, or the presentation layer, provides the capabilities required to deliver IT
functions and data to end users to meet specific usage preferences. This layer can also
provide an interface for application to application communication.
Integration capability
The integration layer is a key enabler for an SOA because it provides the capability to
mediate, route, and transport service requests from the service requester to the correct
service provider and between layers.
These include modest point-to-point capabilities for tightly coupled endpoint integration as
well as more intelligent routing, protocol mediation, and other transformation mechanisms
often provided by an enterprise service bus (ESB). Web Services Description Language
(WSDL) specifies a binding, which implies the location where a service is provided. An ESB,
on the other hand, provides a location-independent mechanism for integration.
The integration that occurs here is primarily the integration of layers 2 through 4. This is for
example the layer that provides the binding between a service definition and the service
implementation by a service Component on layer 2.
Governance capability
The governance layer covers all aspects of business operational life-cycle management in
SOA.
Logical architecture
In more detail, and more concretely, the logical architecture diagram depicted in Figure A-2
on page 25 includes from top to bottom, the consumer layer, business process layer
(Business Process Management Engine), service layer (Enterprise Service Bus), service
component layer (Enterprise Service Bus), operational layer (CRM systems, Billing
Systems,...).
24
ArchitectureGuide.fm
Note: The logical architecture diagram will help you to find a common understanding on
the architecture. All logical components described in the section below can be
implemented by IBM products. This considerably gives the capability to accelerate the
development of such as solution.
From top to bottom, we are going to show the meaning of each of the components of figure
Figure A-2 on page 25. The section will describe:
1. Consumer components
2. Business Process components
3. Corporate Services
4. Service Components
5. Governance Services
Frontend Specific
Data Model
Industry Specific
Business Process
Data Model
WebSphere
Business Process
Management Engine
Business
Process Specific
Mediation Layer
(Industry Specific)
Services
Registry
and
Repository
Corporate
Service
Mediation Layer
(Industry Specific)
Backend Specific
Data Model
Backend
Specific
Mediation Layer
(Provider Specific)
CRM System
Billing System
Figure A-2 Logical architecture diagram for Better Healthcare Insurance ABC
1. Consumer components
Consumer components include a model, a view and a controller.
A model is an object representing data or even activity, e.g. datamodel represented using
XML Schema.
A view is some form of visualization of the state of the model.
25
ArchitectureGuide.fm
Controller
Model
View
In many cases the datamodel of the data used by the consumer components is equal to the
datamodel of the underlying business process components. This is the case when the
consumer components do not include pageflow information disconnected from the business
process layer. In this case it is recommended to make use of the out-of-the-box generator
provided by the IBM BPM suite:
A Lotus Forms Generator given by WebSphere Business Modeler and WebSphere
Integration Developer
A JSF (Java Service Faces) generator included in WebSphere Integration Developer
A Dojo generator included in WebSphere Integration Developer.
In other cases especially when the logic of the controller is getting more complex and
including proper pageflow, it is recommended to implement the consumer components as a
separate completely decoupled layer.
Note: It is not recommended to outsource controller logic from the GUI into the underlying
Business Process components. Logic between pages (pageflow) needs to stay in the GUI
to avoid performance and synchronization issues.
The datamodel depicted in Figure A-4 used by the consumer components includes specific
information, such as specific information to navigate from wizard page to wizard page. It could
also include localization information, such as the language. Orchestration of GUI components
should be directly embedded into the GUI itself.
Frontend Specific
Data Model
26
ArchitectureGuide.fm
advanced pageflow capabilities (wizard like navigation for example), which is not tightly
coupled with the underlying Business process layer.
As of the implementation of a GUI, there are various possible implementation technologies
which can be used to implement the GUI. Examples are JSF, Struts, WebSphere Portal
Server, Lotus Forms, WebSphere Business Space,....
Note: WebSphere Business Space is delivered as a component of the IBM BPM suite. It
includes Lotus Forms technologies to communicate with underlying processes. It has
strong capabilities to accelerate GUI development on the Front End side.
Out-of-the box tools such as the WebSphere Business Space or the Business Process
Explorer act directly on the underlying Business Process datamodel and do not permit an
abstraction on that level.
Note: In some cases, and only when a particular consumer specific datamodel has been
implemented, a mediation layer towards the lower level Business Process layer is required.
This mediation layer is then responsible to map data between the models. It is most often
implemented directly into the graphical layer.
2. Business process components
The business process components include orchestration logic, a datamodel and mediation
logic.
The orchestration or choreography logic is expressed in form of BPEL (Business Process
Execution language for WebServices). This logic is usually imported from a more high
level Business Process design tool such as WebSphere Business Modeler. Within
WebSphere Business Modeler the logic would ideally be expressed in BPMN2.0.
The business process datamodel includes all information necessary to navigate the
Business Process such as conditions, necessary input to retrieve information from
backend services, (e.g customer id, order id,...), measurable metrics, input for Key
Performance Indicators. It is very important to leave this Data Model understandable by a
Business Analyst. It should not contain technical information.
The mediation layer mediates between the business process datamodel and the
underlying layer (Corporate Services components).
More details about the orchestration or choreography logic
The Business Process Management concentrates itself on the execution of Business
Processes. The executable processes, each a choreography of Activities, have to be defined
prior to execution in a process Definition or a Process Template.
WebSphere
Business Process
Management Engine
Concretely for Better Healthcare Insurance ABC, the Business Process Engine will have the
following capabilities:
Execution of the Business Processes
Appendix A. Define a BPM Reference Architecture
27
ArchitectureGuide.fm
Industry Specific
Business Process
Data Model
WebSphere
Business Process
Management Engine
It includes all information necessary to display KPI's, alerts, metrics to the Business
Monitor
It includes necessary information to identify context in the layer below (the Industry
Specific Services Data Model)
It is understandable and maintained by Business Specialists, Business Analysts
It is specified as an XML Schema.
Figure A-7 shows the responsibilities of the business process mediation layer.
The Business process logic (choreography) guarantees the mediation between the Business
Process Layer and the underlying Corporate ESB.
Business
Process Specific
Mediation Layer
(Industry Specific)
28
ArchitectureGuide.fm
Corporate
Service
Mediation Layer
(Industry Specific)
29
ArchitectureGuide.fm
4. Service components
Important: Do not confuse service components with Service Component Architecture.
Service components is a layer in the layered IBM reference approach and has nothing to
do with the SCA framework.
Service components include :
A datamodel used to expose the underlying backend systems as a common service
component architecture. The datamodel is specific to the backend but standardized (xml
schema). For email communication it would for example to, from, cc and subject
information.
Protocol conversion layer (adapters) capable to transform legacy protocols into xml
standardized protocols.
Mapping layer to map between legacy dataformats into standardized (xml) dataformats.
Backend Specific
Data Model
CRM System
Billing System
Examples of these service components are JCA adapters or CRUD services (Create, Read,
Update, Delete services).
The protocol conversion layer (often implemented as an ESB) guarantees the mediation
between the Backend Specific DataModel and the Underlying Backend Protocol. It also
includes specific mapping. The nature of this Bus is usually strongly dependent on the
underlying backend system. It may be for example implemented as :
WebSphere Message Broker for communication with WebSphere MQ based legacy
systems
WebSphere Enterprise Service Bus or WebSphere Message Broker for communication
with JCA adapters which are available for Email, FTP, Flat File, Siebel, SAP and many
others.
ERP specific ESBs such as SAP XI or Oracle ERP specific systems.
Data Access Services implemented on Information Management Information Server
WebSphere Message Broker, DataPower ESB (high performance needs)
WebSphere Enterprise Service Bus or WebSphere Message Broker and CICS adapter
jointly with CICS Transaction Gateway.
Note: Please find information on Adapters at the following link : IM Information Server,
CICS and WebSphere ESB.
5. Governance services
30
ArchitectureGuide.fm
One of the success factors of an SOA is the Governance of its comonents such as services,
processes and policies. Effective Governance is assured thourhg a central Registry in
combination with a central repository. WIthout a Services Registry and Repository, the
corporate IT Services governance could quickly out of control. It is therefore a very important
component within an SOA.
Services
Registry
and
Repository
Implementation approach
Process Models, Key performance indicators, Business Process Datamodels and Screen
Mockups are designed top-down. All decisions for on these artefacts are being taken by
Business directly. For example datamodels are created in a tabulator such as Excel and
then imported into WebSphere Business Modeler. No advanced IT tooling required to
model this datamodels.
Service interfaces and Service datamodels are designed in a meet-in-the-middle way.
The corporate Service layer acts as an agreement layer between business processes and
the operational layer exposed through service components.
Backend systems such as a Billing System or an E-Mail Server, respectively database
accesses (CRUD services) are exposed using application specific interfaces. These
interfaces are generated in a bottom-up way and exposed as service components. The
Service layer above needs to accomodate and map to this layer.
31
ArchitectureGuide.fm
Process
Models
Organizations
Policies
Business
Rules
Business Team
End User
Experience
BPM
Engine
SOA Steering
and governance
team (Business,
Integration and
IT teams)
Business
Rules
Engine
Services
Registry and
Repository
(Policies)
ESB
Corporate
Service
Components
Corporate
Service
Components
JCA
Adapters
Bottom-up implementation effort
Integration Team
Existing
Services
IT Team
Exposed
CRUD service
components
JCA Adapters
Generated
interfaces from
underlying
applications
Existing APIs
to legacy
applications
Important: The corporate service datamodel and interfaces always need to be defined in a
meet-in-the-middle way. Bottom-up and top-down would cause strict dependencies
between the datamodels and considerably reduce the capabilities of the solution layers to
be loosely-coupled.
The outcome of the 4 phases of the Prescriptive Guide Approach generates a BPM solution
which is ready to execute within an SOA Sandbox.
The question in the Deployment phase consists to map this generated BPM layer with
underlying systems and services.
BPM Layer
To make this mapping as smooth as possible, creation of mediation layer between the BPM
layer and the underlying corporate services layer is necessary.
32
ArchitectureGuide.fm
Important: Definition of a mediation layer between corporate service layer and BPM
layer permits both layers to evolve at their pace and guarantees the solution to be
loosely-coupled.
Important: The canonical datamodel is very important in a BPM solution. This layer acts
as an integration contract between the BPM layer (and other layers) respectively the
Service Components (Backend systems). The canonical datamodel should be designed
independently from the efforts in the BPM layer and service component layer.
BPM Layer
Includes a
canonical
data model and Corporate Services Mediation and Mapping Layer
services
Corporate
services
mediation
layer
Represents
backend
services
33
ArchitectureGuide.fm
34