1. ACIS Business Integration Platforms By Bernardo Diaz berdiaz@yahoo.com

2. 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

3. 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.

4. 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.

5. 2. Key Concepts Invoice Mgmt Human Resources Financial Services AccountingITMarketing Production Physical Resources Strategic Mgmt Strategic Mgmt Invoice Mgmt Human Resources Financial Services Marketing Physical Resources Integration Server = ESB Solution…a. Why to Integrate?

6. 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

7. 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 SSSSSSSSS SSS SSS SSS 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

8. 2. Key Concepts c. Integration Types ESB = Enterprise Service Bus

9. 2. Key Concepts c. Integration Types

10. 2. Key Concepts d. Integration Levels

11. 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

12. 2. Key Concepts 1.Level 1: EAI 2.Level 2: Web Services Bus 3.Level 3: Automated SOA e. Service Types 1.Data Services 2.Atomic Services 3.Business Services 4.Workflow Services 5.Automated Services

13. 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.

14. Level1: EAI a. BUSINESS CASE: A typical telecommunications company (ETB) integration. 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 workflow Of 880 business services and an average load 20.000 – 60.000 composite transactions per day.

15. b. ARCHITECTURE. Level1: EAI

16. 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

17. 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

18. 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

19. 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.

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

21. 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

22. Level 2: Web Services Bus 1.WSIF 2.WS - Security 3.BPEL4WS / WS-BPEL 4.WS-C / WS-T 5.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

23. 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

24. 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.

25. 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.

26. Level 3: Automated SOA b. ARCHITECTURE.

27. Level 3: Automated SOA b. ARCHITECTURE.

28. Level 3: Automated SOA 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. c. PRODUCT FEATURES.

29. 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”.

30. 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.

31. 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…?.

32. 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.

33. 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.

34. 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.

35. And Finally… Thank you for your time !!!