Application Connectivity Strategies

Size: px

Start display at page:

Download "Application Connectivity Strategies"

Junior Wiggins
5 years ago
Views:

1 Connectivity Strategies Max Dolgicer Director of Technical Services Gerhard Bayer Senior Consultant International Systems Group (ISG), Inc 32 Broadway, Suite 414 New York, NY Tel: Fax:

2 Agenda Introduction to ISG, Inc Overview of integration options Discussion of application connectivity options Custom adapters Proprietary adapters J2EE Connectors Web service based integration integration scenario 2004 Servers Message Brokers When to choose what 2

3 International Systems Group (ISG), Inc. Leading consulting company specializing in Development of service and component-based Web applications; EAI solutions for both A2A and B2B integration Based in NYC since 1990 ISG differentiator: ISG professionals average 15+ years of real experience in development and integration of enterprise applications using leading edge Middleware technologies Real experience spans End-user corporations and software vendors 3

4 International Systems Group (ISG), Inc. Centers of Middleware Competence TP Monitors, CORBA J2EE Servers Microsoft COM+/.NET Message-Oriented Middleware Message Brokers XML and Web services 4

Layer (Sockets, RPC, MOM, RMI, SOAP, etc.

5 Introduction To Integration Options Packaged Adapter A A 1 A 2 B 1 Standard Adapter B Legacy A 1 A 2 B 2 B 1 Packaged Custom Adapter A B 2 Packaged Adapter B Transport Layer (Sockets, RPC, MOM, RMI, SOAP, etc.) Transformation Routing Business Process Management Platform Services (security, transactions, management, etc.) 5

6 Types of Connectivity Options How different connectivity options are implemented Custom: write your own code Proprietary: provided by vendor in non-standard form Standard: provided by vendor in standard form A 1 A 2 B 1 B 2 Custom Adapter Custom Custom Custom Custom Proprietary Adapter Custom or Proprietary Proprietary Proprietary Proprietary J2EE Connector Custom or Proprietary Standard Proprietary Standard Web Services Custom or Proprietary Standard Proprietary Standard 6

7 Custom Adapters Custom code is developed to connect different applications by calling their APIs Many legacy applications do not have callable APIs In addition, custom code needs to be written to interface with a communication layer TCP/IP sockets Proprietary middleware MOM, middleware bundled with packaged applications Standards-based middleware RMI, SOAP Still the predominant form of integration for most integration solutions that are in production today 7

8 Custom Adapters: Point-to-point Interfaces Custom adapters are usually part of a pointto-point integration architecture: A B C D E F Unresolved issues: More and more applications depend on each other If one application changes, unforeseen ripple effects occur Maintenance complexity increases exponentially with each system that joins the integration architecture 8

9 Dangers of Building Point-to-point Interfaces Publishing application team must Learn two technologies for sending the same message Code twice for the same message since there are two subscribers Test the publishing twice Maintain all of the above Subscriber 1 Publisher 1 New (C++ on NT) If a third subscriber comes along the team must do it again SAP RFC MQ Series Point to point interfaces are not viable long term 9 Packaged (SAP) Subscriber 2 Legacy (Cobol CICS)

10 Custom Adapters Advantage Initial cost can be kept low Compare to high initial cost associated with Message Broker Can be grown over time Can focus on local project, don t need to involve the enterprise (i.e. money, religion and politics) Incremental investment achieves incremental benefits Disadvantage Point-to-point solution Becomes unmanageable Long term cost increase exponentially No organized approach to integration Can not scale to enterprise level Doesn t tie in with higher level tools Routing, Transformation Business Process Management 10

11 Proprietary Adapters Proprietary adapters including packaged adapters are purchased from Adapter vendors iway and others Message Broker vendors IBM, SeeBeyond, TIBCO, Vitria, WebMethods Note: most vendors also provide standard adapters Typically part of a Message Broker solution Adapters use a proprietary interface to communicate with services that the Message Broker provides Communication (synchronous, asynchronous ) Routing, Transformation Business Process Management 11

12 Generic Message Broker Architecture Adapter Management Message Transformer Adapter Adapter Message Message Distribution Dictionary Process Flow Adapter Message Store Adapter Adapter 12

13 Message Broker Solution Message Broker solution employs a (logical) hub and spoke architecture: A B C This approach has important advantages: All applications connect to the hub rather than to each other Overcomes the limitations of point-topoint interfaces D F E 13

14 Advantage Proprietary Adapters Substantial number of adapters are available E.g. iway provides 200+ adapters Smart adapters, built to include Instrumentation for monitoring and management Security, transactions, name service registration Organized approach to integration (if combined with a Message Broker) EAI framework Avoids point-to-point solution Ties in with higher level tools/services Routing Transformation Business Process Management Migration path from A2A into B2B 14

15 Disadvantage Proprietary Adapters High-cost and high-risk approach Requires large initial investment ROI can only be achieved if a significant number of (similar) integration projects reuse the EAI framework BUT: some vendors (e.g. iway) offer a flexible solution that allows to minimize the initial investment and then add tools like transformation, BPM as needed. EAI projects using Message Brokers suffer from skill shortage Compare number of EAI specialist vs. Java programmers vs. Cobol/VB programmers Message Broker are not standards based Use proprietary architecture instead of J2EE BizTalk is not yet.net based 15

16 Standard Adapters:J2EE Connector Architecture Standard architecture for integration between J2EE compliant Server and Enterprise Information System (EIS) Reduces the m-to-n problem EIS vendors don t have to build custom adapters for each application server server vendors don t have to build custom code to integrate with different EIS Standard based alternative for current proprietary solutions 16

17 Resource Adapters Plug & Play Integration Server Enterprise Information System Resource Adapters Server Enterprise Information System 17

18 Resource Adapter Architecture Component Connection Manager Connection Factory Connection Security Manager Pool Manager Transaction Manager Event Listener Managed Connection Factory Local Transaction Managed Connection XA Resource Enterprise Information System Server Resource Adapter 18

19 What s Missing In J2EE-CA? A number of important features are not covered by the current standard, they are implemented by some vendors in a proprietary way: Bi-directional, asynchronous communication Standard client interface (CCI) Support for XML Support for retrieving meta-data about the EIS Other features of the standard were included only in the final release and are not supported by all vendors: Security Transactions 19

20 J2EE Connectors Advantage Standardized approach to integration Single platform for development of new applications and integration with legacy and packaged applications Enterprise Java Beans (EJB) Security and transaction control Client integration (Servlets, Java Server Pages) Integrated resource management (i.e. EIS connections) Disadvantage Centralized architecture Immature, proprietary extensions Complex specification 20

21 Web Services Web services provide a standard for defining the interfaces of a service Including operations, parameters, data types, etc Web services rely on SOAP as a standard protocol (the pipe ) for communication Web Service is a service-oriented encapsulation of business (application) logic Web Services can be implemented in any programming language or object model VB, C++, Java CORBA, COM+/.NET, EJB Web Services can be implemented by encapsulating legacy systems 21

22 Implementation of Web Services SOAP UDDI WSDL Web Server Server Message Broker API API API HTTP JMS other Adapter Adapter New components (EJB) New components (COM+/.NET) Web service platform API Adapter Legacy Systems 22

23 Web Services Advantage Standardized approach for accessing business functions Protocol, data format and interface Packaged application vendors will provide Web services connectors Disadvantage Immature Standards are a moving target Many vendors Problems with interoperability Reliable messaging not part of the current standard SOAP over HTTP vs. JMS? 23

24 Web Services Disadvantage Represents only the tip of the integration iceberg missing/evolving functionality includes Security Transactions Transformation Routing Orchestration (BPM) This functionality needs to be hosted by a server that provides Scalability Reliability Monitoring and management 24

25 Integration Scenario 2004 J2CA Servers Message Brokers Proprietary Adapters Web Services 25

26 Servers And J2CA servers support both J2CA and Web services J2CA provides for more tightly coupled integration Security Transactions Connection management J2CA imposes a centralized model J2CA adapter can only live within a container of the application server 26

27 Servers And Web Services Web Container Request Message SOAP Servlet (in) Message SOAP Servlet (out) Response Legacy JMS Destination JMS Destination SOAP Packets Message Driven EJB EJB Container Server Web service 1 Web service

28 Message Brokers And Web Services Will Web Services replace Message Brokers? Message Brokers will/are support both proprietary adapters and Web service based adapters Some adapters will be based on Web services and become a commodity More sophisticated adapters need proprietary functionality Examples of such functionality: configuration, monitoring and management, transactions, security, Quality of Service (QoS) etc. This is not part of the current standards Standards are always evolving 28

29 Message Brokers And Web Services Message Brokers have already embraced technologies over the last couple of years that can easily evolve into supporting Web services XML Adapters convert data into XML format before it is processed by the Message Broker XSLT XML formatted data allows standard transformation language (XSLT) to be applied XPath A standard mechanism for accessing elements within a XML document 29

30 Message Brokers And Web Services Same issues new approaches Orchestration Registration & Discovery Transformation Adapters Transport Security Transactions Scalability Reliability Management BPM Tools Proprietary, JNDI, LDAP Proprietary Proprietary Proprietary, JMS SSL, PKI, etc. XA, LU6.2 Proprietary, J2EE Proprietary, J2EE Proprietary, SNMP WSFL, XLang, WSCI, BPML UDDI XSLT, XPath WSDL SOAP WS-Security BTP, etc.???

31 What to Select in What Scenario? Today Web services represents only the tip of the integration iceberg Where possible/feasible encapsulate back-end applications/business processes as Web Services There are a lot of tools on the market that do that This will be the first step toward a Service Oriented Architecture (SOA), although Web services should not be used for everything Buy adapters before you consider building them Packaged application adapters vs. custom application adapters Today complex integration scenarios will require proprietary adapters TCO is an important consideration when buying/building proprietary adapters 31

Integrating Legacy Assets Using J2EE Web Services

Integrating Legacy Assets Using J2EE Web Services Jonathan Maron Oracle Corporation Page Agenda SOA-based Enterprise Integration J2EE Integration Scenarios J2CA and Web Services Service Enabling Legacy