ACIS

Business Integration Platforms

By Bernardo Diazberdiaz@yahoo.com

Enterprise Solutions

1. Introduction 2. Key Concepts

3. Level 1: EAI4. Level 2: Web Services Bus5. 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

InvoiceMgmt

Human Resources

Financial Services

Accounting IT Marketing

ProductionPhysical

ResourcesStrategic

Mgmt

StrategicMgmt

Invoice Mgmt

Human Resources

Financial Services

Marketing

PhysicalResources

Integration Server = ESB

Solution…a. Why to Integrate?

2. Key Concepts

a. Why to Integrate? Solution…

1. To consolidate data into strategic information

2. To increase the ROI of Legacy Systems

3. To adapt the business processes of the company to the dynamic market demands

4. To offer strategic services to customers, partners and providers

5. To achieve process automation

6. To improve decision making

1. Integrate all the resources inside of the organization

2. Integrate with related organizations

3. Automate process definitions and external interactions with other companies

2. Key Concepts

b. Basic Integration Elements

Business Entity 1

Integration Server

Business Entity 2

Business Entity 3

Business Entity 4

Business Entity 5

Business Entity 6

Common Language XML

S S S S S S S S S

S S S S S S S S S

Request Mssg

Response Mssg

1. Business Entities

2. Connectors & Adapters

3. Services

4. Messages

5. Common Language (Messaging protocol)

6. Dynamic Business Rules

7. Integration Server

8. Synchronous / Asynchronous Invocation

2. Key Conceptsc. Integration Types

ESB = Enterprise Service Bus

2. Key Conceptsc. Integration Types

2. Key Conceptsd. Integration Levels

2. Key Concepts

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.

d. Integration Levels

2. Key Concepts

1. Level 1: EAI

2. Level 2: Web Services Bus

3. Level 3: Automated SOA

e. Service Types

1. Data Services2. Atomic Services

3. Business Services

4. Workflow Services5. Automated Services

2. Key Conceptsf. 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: EAIa. BUSINESS CASE: A typical telecommunications company (ETB) integration.

Front - Cus tom ers Reques ts

WORK FLOW ENGINE

B ITEC

I n v o ice M g m tD a le e n Te ch n o lo g ie s

A cco u n t in gS A P

O L D I n v o ice M g m t

Fin n a n cia l S e rv ice s

Involved Subsystems:

1. RMCA. (SAP, BAPIS).2. RevChain. (Web Logic 8i, Daleen

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

Server, IONIDEA).

The architecture was proven with a workflowOf 880 business services and an averageload 20.000 – 60.000 composite transactions per day.

b. ARCHITECTURE.

Level1: EAI

B IT E C

Adapta ti on Laye r

Se rvi ce M anagement Laye r

Se rvi ces Laye r

MQ Server

Capa de Servicios

Capa de Adaptación

MDB EJBFacade

Mediator

Proxy

Capa de Administración de Servicios

ServiceManager

S e rv ice 1S e rv ice K

R e v C h a inR M C A

S e rv ice 2

Esquema Asíncrono Esquema Síncrono

WorkFlowManager

C o la En tra d a

C o la Sa lid a

TransactionExecuterServiceFactory

FilterManager

Front

Level 1: EAIc. 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: EAIc. 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: EAIc. 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: EAIc. 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 Busa. BUSINESS CASE: A network of government agencies that share informationthrough public services.

Level 2: Web Services Busb. 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

1. WSIF

2. WS - Security3. BPEL4WS / WS-BPEL4. WS-C / WS-T5. WS-Policy 6. CS – WS

7. WS-… ETC.

b. Web Services = UNESTABLISHED TRENDS.

1. Lack of consensus and standardization

2. Parallel specification efforts toward the same objectives

3. Different specification approaches (BPM)

4. There is no a single solution to every problem, new customer needs arise frequently

Level 2: Web Services Bus

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

b. Web Services = Use only established standards SOAP, WSDL, WS-I,

WS-Security

Level 2: Web Services Busc. 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 Busc. 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 theremust be a WS Bus performing the role of service broker.

Level 3: Automated SOAb. ARCHITECTURE.

Level 3: Automated SOAb. ARCHITECTURE.

Level 3: Automated SOA1. 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.

c. PRODUCT FEATURES.

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 !!!