Comparison of

Traditional Business Process Automation

and Data Service Integration Styles

1
 Topics
• Discussion of integration service styles within an
enterprise when using:
– A Common Inf ormation Model (CIM)
• e.g. OAG Can onical Business Language
– Standardized business processes
• e.g. OAG Bus iness Process Scenarios
• How do traditional Business Process Automation
(BPA) style adapters work
– Single Purpose Servic es such as: PublishNewPO ();
• e.g. OAG m essage adapters and OAGIS W SDL
• How do data service style adapters work
– Generic Services such as: Publish(PO );
• Comparison 2
 OAG Integr ation Scenario

Defines
standard
business
process for use
within an 3
enterprise
Traditional Business Process Adapters
Application is supplier of E, F, and H and consumer of G.
Standardized process requires that E and F be joined in outgoing message

Native App CIM Traditional

Classes Classes Join hard BPA Services
coded in
A adapter

E/F NotifyEF();
B
SubG();
C G
D H

H not part of any exi sting 4

standardized business process
Traditional Business Process Adapters

Non Native CIM Non Native CIM

Application Application

Native data exported/i mported using

XML or via legacy API

BPA Style Transform/join native representation BPA Style

Adapter from/to CIM mes sage contents Adapter

Publish/Receive only the standardized

messages in CIM format (XML )
CIM Based Message Bu s
5
Traditional Business Process Adapters

• Alternatively, one could just use adapters

to put native data on the bus i n XML and
do all transformati on/joining in a more
centralized Business Process Automati on
(BPA) orchestrati on environment.
However this architecture precl udes the
supply of off-the-shelf CIM adapters b y
vendors.

6
 Alternate Ar chitecture
Non Native CIM Non Native CIM
Application Application

Native data exported/i mported using XML or via

legacy API for standardized transactions

BPA Style Only converts to JMS or WS, BPA Style

Adapter but not data c onversion Adapter

Publish/Receive standard mess ages in native format (XML)

Native/CIM Based Integra tion Bus

Transform message contents

BPA Orchestration Join E and
from/to nati ve representati on 7
Environment F centrally
into CIM Objects
Traditional Business Process Adapters
• Standardized Business Process is encoded in the
Adapter
– Changing the business process requires that the data
transformation/join code in the adapter change.
– BPA orchestration envi ronment not f ully enabled
because adapters don ’t support a query with “where
clause”. You are conf ined to the messages encoded f or
the standardized transactions
• Example: A new Purchase Order BPA orc hestration script
defines a special process for when the value of the PO is greater
than 10. For example, if the value is greater than 10, then find
out which salesperson made the sale. If the sales person’s
name is not in the original standardized process, how does the
BPA script get it? An orchestration script can’t query for the
name using a where clause unless the business process (that
specific query) is hard-coded in the traditional BPA adapter. 8
 Traditional Business
Process Adapters

• Traditional Business Process Automati on

adapters for use wi thin an enterpri se are
limited to a predefi ned set of transacti ons
– While standard business processes may be required
for inter-enterprise messaging, they are overl y
restrictive when discussing processes within an
enterprise
– Standardized Business Processes are typicall y not
used exactly as is
– Can’t support other types of integration
9
 Enterprise Integration

• There are several major categories of Intra-

Enterprise Integration including:
– Business Process Automation (BPA): T wo or more
applications exchange messages for operational
needs.
– Data warehousing (ETL): Data is periodically
extracted and transf ormed from a variety of data
sources and loaded into a speci fic database for
analysis.
– Enterprise Inf ormation Integration (EII): Combining
data on an ad hoc basis f or analysis.

10
 Comparison of Requirements
for BPA, ETL, and EII Use Case

• The data exchanged within an

enterprise for the ET L and EII use
cases is more open ended.
– Difficult to predefine a limited set of
transactions that sati sfy BPA and
ETL/EII

11
 Enterprise Integration Services
Design Principles
• One should try to internalize application
business logic in a vendor’s product
– The vendor products know best how to handle data
manipulation at an application level.
• One should try to externalize business process
logic from a vendor’s product
– Business Process Automation orchestration should
be done centrally: Custom orchestration enabl ed for
every enterprise.
– This allows an off -the-shelf adapter to be used even
when business processes vary. 12
Going Beyond Fixed BPA St yle Adapters

• Need a way to adapt to changing business

processes
• Need a way to support all integration use cases
• Need a way for vendors to supply CIM application
adapters off the shelf
• Data Service based adapters fulfill these
requirements. A Data Service includes:
– Unified Address Space with unif ied way of identifying
information
– Generic query with a where clause
– Generic update request (di fferent from a database write)
– Generic event noti fication with rich content f iltering
13
 Where do Data Services Fit In

Business Process Create PO

Service Layer Purchase Processing
Order Report Service
Registry

Application
Analysis tools Process Workflow
Development And Libraries Scheduler Engine
Single
Service Layer Sign-on

Data
Generic Data Access Read/Write/Query
Service Time
and Event Notification Services Sync
Layer

Legacy Databases
Applications and and Content
Messaging Applications Platform
System
Data Layer Repositories Services
14
 The Benefit of Separating Business
Logic from Application Adapters

Separating Business
Services from Data Business Process Create PO
Service Purchase Processing
Services enables Layer Order Report Service
Registry
business logic to
change without Application Analysis tools Process Workflow
Development Single
changing application And Libraries Scheduler Engine
Sign-on
Service Layer
adapters and
Data
therefore enhances Generic Data Access Read/Write/Query Time
Service and Event Notification Services
the ability to create Layer
Sync

off-the-shelf adapters
Legacy Databases
Applications and and Content
Messaging Applications Platform
System
Repositories Services
Data Layer

15
 Data Service Based Ad apters
• Data Service Style Adapters use business process neutral
services at the adapter
– All data that the vendor wants to expose as CIM data is available.
This can be supplied off the shelf by the vendor if standard
Query/Read/Write/Event Notification Data Services are defined.
• Data Services should:
– Include unified way to indentify information (unified address space
that includes type and instance information).
– Include generic query/update interface, but does not assume the
capabilities of a relational database
• For exampl e, No DB write capability, just an update reques t as
supported in a version control system so that application business
logic remains in the application
– Include generic event notification that leverages standard message
payloads and the ability for a server to expose what message types
and object instances it supplies data for.
• Object instances exposed in a browseable address space which is
used by clients to create a content filter via point and click.
• Type info and content fi ltering used during subscription and query 16
 Data Service Style Ad apter
App is supplier of E, F, and H and consumer of G

Native App CIM Data Sevice Query

Classes Classes And Update Servi ces

A E
B E/F Query(Classes, Filter, join);
Notify(Data);
F Subscribe(Data,Filter);
C G Update(Data );

D H

H not part of any exi sting 17

WG 14 business process
 Data Service Adapter
Legacy Legacy
Application Application

All public native data expos ed using

XML or via legacy API

Data Service Transform all relevant publi c native data Data Service
Adapter from/to legacy representation into CIM Obj ects Adapter

Servers expose all relevant pubic

data as a CIM address space

CIM Integration Bus

All business processing BPA Orchestration
done in the BPA BPA Orchestration Environment has acc ess to
Orchestration Environment Environment all public CIM data 18
and not in the Adapter
 Data Service Style Integration Leverages and
Extends Work Done B y Groups Such As The OAG

• Business Process is NOT encoded in the Adapter but is

entirely contained in the central BPA orchestration scripts
– Use standardized message payloads to define a base set of
messages that are supported by an application off the shelf – but the
standard messages are not the limit of what an application exposes
– All business process logic developed and executed in a centralized
BPA orchestration environment
– Vendor supplied off-the-shelf adapters expose all native data that is
mapped to the CIM.
– Not all data is used when adapter is deployed because not all data
needed by current business processes. However, data need not
persisted in CIM format so overhead of having the ability to transform
all data is negligible
– Complementary with the use of tools such as Tibco for
transformation of data and as BPA Orchestration Environment
19
 Example Traditional BPA Integration
BPA Orchestration Envi ronment
Actual Script:
Original App1 pub EF
Standardized Script then App 2 pub
App1 pub EF then G then App1
App 2 pub G Pub H
NotifyEF();

SubEF();
NotifyG()
SubG()

Native API and Native API and

Data transformation Data transformation

Application 1 Application 1
Supplier of E, F, and H Supplier of G and
and consumer of G consumer of E, F, and H
20
Example Data Service In tegration
BPA Orchestration Envi ronment
Not in the original standard Actual Script:
Original business process, but can be
App1 pub EF
compensated for in BPA script
standardized Script then App 2 pub
App1 pub EF then G then App1
App 2 pub G Pub H
Notify(EF);

Update(H )
Query(H)

Sub(EF);
Notify(G)
Sub(G)

Native API and Native API and

Data transformation Data transformation

Application 1 Application 1
Supplier of E, F, and H Supplier of G and
and consumer of G consumer of E, F, and H
21
 Data Service Adapters

• Address ETL and EII use cases by providing:

– Rich BPA orchestration environment as adapters
support query with “where clause ”.
– Data service should not presume the capabilities
of a relational database since many legacy API ’s
don’t have this capability.
– One down side is that adapters are more complex
to build. However, this needs to be done less
frequently since a reusable reusable adapter can
be supplied off the shelf by the vendor or a thi rd
party.
22
 The Bottom Line

• Today, because of the lack of interoperable

products, enterprise integration is custom work
done by system integrators.
• This integration work comprises a large portion
of money allocated to the use of applications.
• The use of OPC UA Data Services goes a long
way towards shrinking the “integration gap” and
thereby allows vendors to better meet the
needs of users.

23