Distributed Component Architectures for Cooperative Information Systems

1
Distributed Component Architecturesfor
Cooperative Information Systems

• Edward Cobb
• Vice President, Architecture Standards
• BEA Systems
• ed.cobb_at_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

3
Agenda

• Todays Business Environment
• Evolution of Component Technologies
• Desktop Objects
• CORBA and DCOM
• Object Transaction Monitors
• Java and J2EE
• Microsofts .NET
• Loosely-Coupled vs. Tightly-Coupled
• Convergence via Web Services
• Conclusions

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

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.

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

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
  Microsofts Windows
• Has become the preferred approach for all GUI
  development
• A tightly-coupled model

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)

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

10
Common Object Request Broker Architecture (CORBA)
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)
• Microsofts MTS

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

13
Application Server Architecture
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

15
J2EE 1.3 Architecture
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

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

• 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

Many EJB applications will use both!
Entity Beans
Session Beans
(via explicit JDBC when automated tools are
insufficient)
(Inventory agent, MTS style)
(Web shopping cart)
(via O/R mapping)
Stateful
Stateless
Bean- Managed
Container- Managed
19
EJB Architecture
User Code
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
20
Microsoft .NET

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

21
Loosely-Coupled and Tightly-Coupled Architectures

• 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

Web Services is an architecture for
loosely-coupled applications
22
Business Rationale for Loose CouplingBooking a
Business Trip
23
Web Services Architecture
24
Web Services Definition
25
Web Services Characteristics

• XML based
• Locatable via a registry
• Accessible over the web
• Loosely-coupled
• Message-based
• Standard Web Protocols

26
Whats 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

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

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

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.

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

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 XMLs Web impact will be on
  restructuring the economics of Web-based
  transactions - Rita Knox, Gartner Group