Distributed Component Architectures for Cooperative Information Systems

1. Distributed Component Architecturesfor Cooperative Information Systems Edward Cobb Vice President, Architecture & Standards BEA Systems ed.cobb@bea.com 7 September, 2001

2. Trademarks • The following are trademarks of the Object Management Group • CORBA – UML • The following are trademarks of Sun Microsystems • Java – J2EE • JavaBeans – J2SE • Enterprise JavaBeans – J2ME • The following are trademarks of their respective companies: • WebLogic - BEA Systems • Websphere - IBM Corporation • iPlanet - Sun Microsystems/AOL • Microsoft .NET - Microsoft Corporation COOPIS 2001 - Trento, Italy

3. Agenda • Today’s Business Environment • Evolution of Component Technologies • Desktop Objects • CORBA and DCOM • Object Transaction Monitors • Java and J2EE • Microsoft’s .NET • Loosely-Coupled vs. Tightly-Coupled • Convergence via Web Services • Conclusions COOPIS 2001 - Trento, Italy

4. Today’s Business Environment • Increased Competition • Time to Market • Flexibility • Adaptability • Cost Containment • Shortage of IT skills • “Do More with Less” • IT contribution to bottom line • Pace of Technology Innovation • Difficult to Keep Up • Opportunity to gain and maintain competitive advantage COOPIS 2001 - Trento, Italy

5. What is a Component? • A self-contained unit of software code with • its own data and logic • well-defined connections or interfaces • exposed for communication. • Designed for repeated use • in developing applications • with or without customization. COOPIS 2001 - Trento, Italy

6. Why Components? • Time to market • Improved application developer productivity • Reduced complexity • Reuse of existing code • Programming by assembly (manufacturing) rather than development (engineering) • Reduced skills requirements • Focus expertise on domain problems • Key benefit will be seen with server-side development COOPIS 2001 - Trento, Italy

7. Objects on the Desktop • Key to Graphical User Interfaces (GUIs) • Pioneered by the Apple Macintosh • Brought to the PC by Microsoft and IBM • Key Enabling Technology for the success of Microsoft’s Windows • Has become the preferred approach for all GUI development • A tightly-coupled model COOPIS 2001 - Trento, Italy

8. The Client/Server Revolution • Local Area Networks make Sharing Efficient and cost-effective • Devices (e.g. printers) • Files • Databases • Power to the Desktop User • Applications Reside of Client Desktop • Rise of Powers tools (Microsoft Visual Basic, Sybase Power Builder) for the desktop programmer • Servers used for fixed function (data and device access) COOPIS 2001 - Trento, Italy

9. Objects on the Server • Two competing alternatives • CORBA from the Object Management Group (multi-language, multi-OS, and vendor neutral) • DCOM from Microsoft (multi-language but Windows only) • Interface Definition Language (IDL) • Defines the contract between client and server • Forms the basis of the on-the-wire interoperability protocol • Based on a tightly-coupled RPC model • Both had limited success • Distribution costs of fine-grain objects • Scalability problems inherent in client-server architectures • Complexity of supporting multiple programming languages COOPIS 2001 - Trento, Italy

10. Common Object Request Broker Architecture (CORBA) COOPIS 2001 - Trento, Italy

11. Object Transaction Monitors • A need breed of application middleware • Not a CORBA ORB with a “suite” of services • Not a TP monitor with O-O language binding • a new software platform built from “open standards” • a component-based development model • AND the performance and “abilities” of a TP monitor • Examples: • BEA WebLogic Enterprise (previously called M3 and now part of BEA Tuxedo) • Microsoft’s MTS Object Computing Europe 98 - Helsinki

12. Java Makes CORBA a Big Success • Rise of the web shifts focus from client to the server • Virtual machine architecture provides better portability and security • Java programming language eliminates many of the complexities of C++ • Focus on portability rather than interoperability • Single language results in APIs which are more natural for the Java programmer than IDL mappings of CORBA APIs COOPIS 2001 - Trento, Italy

13. Web Clients (via Web Server) Component, Object Clustering (routing, load balancing, failover) State Data State Data Web Clustering (routing, load balancing, failover) Firewall, Net Director Web Server HTTP routing (e.g., Net Director), Firewall Servlet/ JHTML/JSP Enterprise JavaBeans Servlet/ JHTML/JSP Enterprise JavaBeans Web Container Application Container Web Server State Data State Data Servlet/ JHTML/JSP Enterprise JavaBeans Servlet/ JHTML/JSP Enterprise JavaBeans Web Container Application Container Web Clients State Data Enterprise JavaBeans Programmed Clients Enterprise JavaBeans Application Container Application Server Architecture COOPIS 2001 - Trento, Italy

14. What is J2EE? • One of three Java platform specifications • Java 2 Micro Edition (J2ME) • Java 2 Standard Edition (J2SE) • Java 2 Enterprise Edition (J2EE) • A Java API specification for Enterprise Applications • Includes J2SE plus • Web container • EJB container • The architecture of the Application Server • BEA WebLogic • IBM Websphere • Sun iPlanet COOPIS 2001 - Trento, Italy

15. Applet JSP Servlet EJB HTTP SSL DB Java Mail Java Mail J2SE JTA JTA JAA JCX JAA JCX JMS JMS JAXP JAXP JDBC JDBC HTTP SSL JAF JAF J2SE Application Client J2SE HTTP SSL JTA JAA JMS JDBC J2SE J2EE 1.3 Architecture COOPIS 2001 - Trento, Italy

16. Web Container • Client Access • HTTP(S) Clients with HTML • HTTP(S) Clients with XML documents • Programming APIs • Servlets • Java Server Pages (JSP) • Dynamic HTML content • Custom Tag Libraries • XML parsing (JAXP) in J2EE 1.3 • Back-end access • EJBs via Java RMI • DB via JDBC • Enterprise Information Systems via JCA in J2EE 1.3 COOPIS 2001 - Trento, Italy

17. EJB Container create find remove EJB Home implements all lifecycle services for the bean. EJB Home (bean identifier) Client EJB Object Enterprise Bean EJB Object Enterprise Bean methods EJB Object Enterprise Bean EJB Object (client view) Enterprise Bean EJB Object provides a client view of the enterprise bean. It intercepts all calls and performs transaction, state, persistence, and security services for the bean. COOPIS 2001 - Trento, Italy

18. Session Beans “TP Monitor” style Short-lived, no key 1-to-1 relationship to client Explicit DB access E.g., Bank Teller, E-Commerce Server EJB Taxonomy Enterprise JavaBeans Entity Beans Component view of DB row or object May be long-lived Primary key, stateful 1-to-many relationship to client(s) E.g., Customer, Order Many EJB applications will use both! Session Beans Entity Beans (via explicit JDBC; when automated tools are insufficient) (Inventory agent, “MTS style”) (Web shopping cart) (via O/R mapping) Stateless Stateful Container- Managed Bean- Managed COOPIS 2001 - Trento, Italy

19. DBMS User Code EJB Architecture Generated Code All else, system code EJB Server EJB Container Client EJB home object EJB home stub EJB Object Stubs Enterprise Beans EJBObjects Deployment Descriptor COOPIS 2001 - Trento, Italy

20. .NET Platform Infrastructure + tools User experience Building blocks Mega services .NET Products and services Windows.NET MSN.NET Personalized subscription services Office.NET VisualStudio.NET VB style Generates XML bCentral.NET BizTalk Business process orchestration CRM services Third party .NET services Building-block services Identity (Passport) Notification and messaging Unified IM, e-mail, voice mail, … Personalization XML store SOAP Data description Unified data access??? Calendar service Directory and search Dynamic delivery Microsoft .NET COOPIS 2001 - Trento, Italy

21. Tightly-Coupled High Degrees of Interdependence Difficult to change parts Synchronous Invocations (RPCs, conversations) Implicit State Sharing Implicit Contexts 2PC Transactions Best for intra-enterprise CORBA 2, J2EE 1.2, and DCOM are all tightly-coupled Loosely-Coupled Greater Independence Much easier to change parts Asynchronous invocations (messaging) Meta-Data Sharing Explicit Contexts in messages Workflow Ideal for inter-enterprise (web) CORBA 3, J2EE 1.3, and .NET add loosely-coupled capabilities Loosely-Coupled and Tightly-Coupled Architectures Web Services is an architecture for loosely-coupled applications COOPIS 2001 - Trento, Italy

22. Business Rationale for Loose CouplingBooking a Business Trip COOPIS 2001 - Trento, Italy

23. Web Services Architecture COOPIS 2001 - Trento, Italy

24. “Web services are content and software processes delivered over the Internet using loosely coupled messages (and increasingly, XML interfaces) that ‘service’ a particular set of user needs.” David Smith, Gartner Group 11 October 2000 Web Services Definition COOPIS 2001 - Trento, Italy

25. Web Services Characteristics • XML based • Locatable via a registry • Accessible over the web • Loosely-coupled • Message-based • Standard Web Protocols COOPIS 2001 - Trento, Italy

26. What’s Different with Web Services? • Standardization moves to Schema/DTD space • Focus on exchange of complete documents rather than just core information • Versions of schemas used critical to communication • Interoperability rather than Portability but… • As with standard protocols, little work in self-defining documents and interchange (vs. dynamic interface discovery) • Still have to code business logic and create/parse XML • Closer to EDI than to traditional networking • Long-lived business transactions (not 2PC) • Simpler model of interaction than businesses currently use COOPIS 2001 - Trento, Italy

27. Web Services Framework • Wire (or exchange format) • The components representing what is sent during a given exchange; data, the envelope and the metadata necessary for a meaningful transmission • Description • The specifications required for the format definition, use or application of the wire components • Discovery • The specifications that provide the mechanisms for automatic searching and discovery of the components in the Wire and Description stacks COOPIS 2001 - Trento, Italy

28. Wire (or exchange format) • Message Envelope and controlled extensibility (XML) • Versioning • Mandatory and optional message parts • Message components for different intermediaries • Binary attachments • Message Exchange (Routing) • The means to designate different intermediaries and their expected response. • Intermediaries identified by service type COOPIS 2001 - Trento, Italy

29. Description • XML Schemas • Service Description • Web Services Definition Language (WSDL) • Messages, sent and received, protocols used to exchange them, logical ports associated with services, binds to address(es) • Functionally analogous to IDL • Process Flow Orchestration • Valid sequences of messages • Relationships between messages and the business processes they initiate • Relationships between messages and the (external) contractual provisions they pertain to. COOPIS 2001 - Trento, Italy

30. Discovery • Inspection • Protocols enabling a web service to obtain metadata about itself such as • a service description • process flow or • related contracts. • Discovery (UDDI) • A protocol to obtain identifiers of services based on given characteristics • Functionally similar to CORBA Trader COOPIS 2001 - Trento, Italy

31. Conclusion • The Next Generation Web will be based on communicating programs not browsers • These programs need a common language to exchange information • XML is being adopted as that common language • meets the functional requirements • has support from all major vendors • is an open standard • “The brunt of XML’s Web impact will be on restructuring the economics of Web-based transactions” - Rita Knox, Gartner Group COOPIS 2001 - Trento, Italy