ACIS

Business Integration Platforms

By Bernardo Diaz
berdiaz@yahoo.com
Enterprise Solutions

1. Introduction
2. Key Concepts

3. Level 1: EAI
4. Level 2: Web Services Bus
5. Level 3: Automated SOA

6. JBI Integration
1. Introduction

 Globalization has brough back a problem to the

software industry. And right now the software
industry has not provided a definite solution.

 Organizations require to exchange consolidated,

strategic and real time information to customers,
business partners and providers (through business
services).

 The information systems of the organization must

be thightly integrated (but not coupled).

 Integration is not an IT trend, is a business and

world-wide requirement.
1. Introduction

 SOA pretends to be the software industry response

to the Business Integration Equation.

 Organizations have highly heterogeneous

environments.

 SOA must avoid to introduce noise to the

organization by forcing the adoption of a particular
technology.

 SOA must be a feasible solution based on low

adoption cost and easy integration to legacy
systems.
2. Key Concepts
a. Why to Integrate? Solution…

Invoice Human Financial Strategic Human Physical

Mgmt Resources Services Mgmt Resources Resources

Integration Server = ESB

Accounting IT Marketing

Invoice Financial
Marketing
Mgmt Services
Strategic Physical
Production
Mgmt Resources
2. Key Concepts
a. Why to Integrate? Solution…
1. To consolidate data into 1. Integrate all the resources
strategic information inside of the organization
2. To increase the ROI of Legacy
Systems 2. Integrate with related
3. To adapt the business organizations
processes of the company to
the dynamic market demands 3. Automate process definitions
4. To offer strategic services to and external interactions with
customers, partners and other companies
providers
5. To achieve process
automation
6. To improve decision making
2. Key Concepts
b. Basic Integration Elements 1. Business Entities

2. Connectors & Adapters

Business Business Business
Entity 1 Entity 2 Entity 3

Request 3. Services
Mssg S S S S S S S S S

4. Messages

Integration Server Common Language XML 5. Common Language

(Messaging protocol)

6. Dynamic Business Rules

S S S S S S S S S Response
Mssg
7. Integration Server
Business Business Business
Entity 4 Entity 5 Entity 6
8. Synchronous /
Asynchronous Invocation
2. Key Concepts
c. Integration Types

ESB = Enterprise Service Bus

2. Key Concepts
c. Integration Types
2. Key Concepts
d. Integration Levels
2. Key Concepts
d. Integration Levels

 Level 1. Enterprise Application Integration. Integration of legacy systems

inside the organization (Backend Integration). EAI = Basic ESB

 Level 2. Public level Integration (front-end integration), Integration among

organizations (B2B). At this level the ESB must be WS enabled.

 Level 3. Automated Integration. Implies the use of meta-services based on

management policies to define security, versioning, dynamic routing and
conversational support. By adding a Business Process Management Engine
and repository, full governance can be accomplished.
2. Key Concepts
e. Service Types

1. Level 1: EAI 1. Data Services

2. Atomic Services

2. Level 2: Web Services 3. Business Services

Bus

3. Level 3: Automated 4. Workflow Services

SOA 5. Automated Services
2. Key Concepts
f. Business Process Management

 Could be implemented at any level (1, 3), inside the

organization or among organizations.

 It is suited exclusively for long running transactions that

span asynchronous services.

 Complex decision making rules determine the routing

between activities (services).

 Unfortunately there is lack of consensus and

standardization among proposals (XPDL, BPEL, BPML).

 The use of WS technologies enables to encapsulate any

Workflow engine implementation as another Web Service.
Level1: EAI
a. BUSINESS CASE: A typical telecommunications company (ETB) integration.

F ro n t - C u s to m e rs R e q u e s ts Involved Subsystems:

1. RMCA. (SAP, BAPIS).

B IT E C
I n v o ic e M g m t
D a le e n T e c h n o lo g ie s
2. RevChain. (Web Logic 8i, Daleen
W O R K F LO W E N G IN E
Technologies, J2EE).
3. EnlaC. ETB’s front end/CRM 2.0
(Oracle IAS 9i, J2EE).
4. SGS / SAAC. ETB’s front end 1.0
(Oracle PL/SQL).
5. Financiador. (JBoss, J2EE).
6. IDEA 1.0. (SUN ONE Integration
F in n a n c ia l S e r v ic e s Server, IONIDEA).
O L D I n v o ic e M g m t
A c c o u n tin g
SA P The architecture was proven with a workflow
Of 880 business services and an average
load 20.000 – 60.000 composite transactions
per day.
Level1: EAI
Esquema Asíncrono Esquema Síncrono
b. ARCHITECTURE.

Front

MDB EJB
C o la E n t r a d a Facade

A d a p ta tio n La y e r FilterManager

C o la S a lid a Mediator

MQ Server
Proxy
Capa de Adaptación

ServiceManager WorkFlowManager
S e rvic e M a n a g e m e n t La y e r
ServiceFactory
TransactionExecuter

Capa de Administración de Servicios

S e r v ic e K
S e r v ic e 1 S e rv ic e 2

S e rvic e s La y e r
Capa de Servicios

B IT E C

R M C A
R e v C h a in
Level 1: EAI
c. PRODUCT FEATURES.

1. Integrates heterogeneous Business Entities through a common data

bus

2. It is based on the concept of services published by legacy systems

3. Uses custom adapters as message or communication channels

4. Enables either synchronous / asynchronous invocation of any

published service

5. Predefined Connectors:
 J2EE – HTTP, EJB, JMS
 SAP – BAPIS
 Daleen Technologies
 SQL – Custom Queries, Stored Procedures
Level 1: EAI
c. PRODUCT FEATURES.

6. Dynamic Business Rules can be applied during pre or post processing of

the transaction.

7. Supports multiple message formats (transformations, mappings)

8. Common Language. Has an internal xml based metadata language to define

Invocations, transactions, services and workflow.

9. Service Compositions:

 1 Invocation : n-transactions
 1 transaction : n-services
 1 business service : n-atomic services

10. All the features have declarative support through xml configuration files
Level 1: EAI
c. PRODUCT FEATURES.

11. Distributed Transactions (XA-2PC)

12. Embedded Compensation Logic

13. Includes timeout and retries features

14. Audit

15. Workflow Levels:

 Declarative, static
 Dynamic, through metadata-policies inside the message header
 Automated, through a BPM Engine
Level 1: EAI
c. PRODUCT FEATURES.

16. Based on standard Java technologies (spec J2EE 1.3, 1.4).

17. Can be installed in any J2EE compliant application server and java compliant
operating system.

18. Pluggable Components. Life Cycle enabled (start, stop, restart).

19. Parallel Processing. Components can be pooled declaratively according to

work loads.
Level 2: Web Services Bus
a. BUSINESS CASE: A network of government agencies that share information
through public services.
Level 2: Web Services Bus
b. ARCHITECTURE.

1. Generic WS Facades

2. Interoperability. WS-I / WSDL

compliant services.

3. Security

4. Service Registry + Smart

Routing = Service Broker
Level 2: Web Services Bus
b. Web Services = UNESTABLISHED TRENDS.

1. Lack of consensus and

1. WSIF standardization

2. WS - Security 2. Parallel specification efforts

3. BPEL4WS / WS-BPEL toward the same objectives

4. WS-C / WS-T
3. Different specification
5. WS-Policy approaches (BPM)
6. CS – WS
4. There is no a single solution
7. WS-… ETC. to every problem, new
customer needs arise
frequently
Level 2: Web Services Bus
b. Web Services = Use only established standards SOAP, WSDL, WS-I,
WS-Security

1. Enables transparent
publishing of Level1 and
Level 2 services.

2. Portable across hardware,

operating and software
platforms: XML

3. Interoperable: If based on
the WS-I recommendation
Level 2: Web Services Bus
c. PRODUCT FEATURES.

An EAI can be transformed into a Web Service Bus:

 By adding a WS-I compliant channel without modifying existing services.

 Every organization should publish a subset of previously integrated services

 At this level, security must be implemented to guarantee authentication,

authorization and data protection. Lack of standardization forces to implement
custom solutions based on header metadata, encryption and digital
signatures.
Level 2: Web Services Bus
c. PRODUCT FEATURES.

4. A Service Directory can be added (published itself as a web service node)

to centralize the location of each service.

5. By using the capabilities of WSDL and the Apache/Jakarta framework WSIF,

the service directory can be evolved into a Service Broker, by adding smart
routing capabilities.

Finally inside each org there must be an EAI Bus and in the WS Network there
must be a WS Bus performing the role of service broker.
Level 3: Automated SOA
b. ARCHITECTURE.
Level 3: Automated SOA
b. ARCHITECTURE.
Level 3: Automated SOA
c. PRODUCT FEATURES. 1. The first step toward automated
governance is to define metadata in
the form of attributes and action
commands.

2. Several management nodes could be

implemented but interaction begins
with distributed security policies.

3. Interaction could be implemented in a

dynamic fashion among nodes, based
on conversational support.

4. MetaServices: A Web Service

Integration Network seems as a
federated topology due to the fact that
management is encapsulated as
Metadata Web Services.

5. Full automation (Governance) can be

achieved by including a BPEL Engine.
JBI – JSR 208
1. Existing SOA solutions should be JBI
compliant.

2. The JBI Container could be extended by

adding the new WS-X protocols.

3. Interoperability reaches a new meaning:

“Integrating the integration”.
JBI – JSR 208
1. The spec is too coupled with Messaging &
WS concepts.

2. Data abstraction is not adressed by the

spec.

3. Dynamic service bindig is not adressed by

the spec.

4. Service Policies or conversational state are

not adressed by the spec.
Missconceptions
1. Business Services. ¿is it the same service vs. Web
Service?.

2. ¿Is it the same SOA vs. Business Integration?.

3. Refactoring the Wheel. ¿is it the right path to

develop a new programming model/tools based on
multiple xml web service specs?.

4. Integration must be Technology Agnostic.

¿should integration be based on Web Services,
Messaging or BPM?.

5. Lack of Concensus and thus standarization. ¿are

we back to the client/server kind-of era?, ¿What is the
real matturity of our industry…?.
Conclusions

 SOA must be based on Business Services NOT

Web Services.

 Integration is a business necesity, SOA is a

technological trend that tries to solve it.

 Refactoring the Wheel. Definitely our GURUS and

MOGULS should try to get as soon as possible
trainning in common sense and software
architecture.
Conclusions

 Integration must be Technology Agnostic. All

of these tools have a time and a place in a business
integration escenario but must be behind an
integration server not to the eyes of the users.

 Lack of Concensus and thus standarization. The

strenght of modern architecture is standarization
and concensus, without it we are back to the
client/server era. Not to mention all the advantages
to our customers.

 Business Integration must be OS/and software

platform independent, thus SOA products are ideally
suited to the wonder duo of Java and XML.
Conclusions

 A SOA platform must support dynamic

service invocation as the base of
complex service compositions.

 To support Governance, service

policies and conversational state must
be adressed.
And Finally…

Thank you for your time !!!