Integration

Document Sample
Integration Powered By Docstoc
					       Selecting the Best
Distributed Collaboration Styles
              for a
       J2EETM Application

              O’Reilly
    Conference on Enterprise Java
     Wednesday, March 28, 2001


           Grant Holland
        Senior Java Architect
          Sun Java Center           1
                 Purpose

• To develop a requirements-based model for
  selecting the best collaboration styles for a
  J2EE application.




                                            2
                 Topics
• Distributed Collaboration
• Four Generations of Local and Distributed
  Collaboration
• What about Loose Coupling?
• Understanding Communications
  Middleware
• A Model of Distributed Collaboration Styles
• Collaboration Styles in J2EETM Applications
• Selecting the Best Collaboration Styles for a
  J2EE Application
• Conclusions                                     3
Distributed Collaboration

  “The network is the computerTM”


                                    4
 Distributed Collaboration
– What is software collaboration?
  • Program-to-program (module-to-module)
    interactions
  • All software collaborations (local or distributed)
    must accomplish both of these responsibilities:
     – 1. Control Dispatch
         » Coordinating execution control between two or
           more modules, so that some particular action
           (service) can be executed.
     – 2. Parameter Marshalling
         » Transferring related data from programming
           variables in one module to programming
           variables in the other module(s).        5
   Distributed Collaboration
– What is required to accomplish any (local or
  distributed) collaborative software
  interaction?
  • 1. Locate the target module (object)
  • 2. Locate and transport any data values and their
    types among the collaborating modules
  • 3. Dispatch control to the target service (method)
  • 4. Coordinate (synchronize) various interactions
    among the collaborators
     – Send request, receive request, process appropriate
       action, send response, receive response
                                                       6
   Distributed Collaboration
– The question is…
  • Who is going to handle all of this…
     – the application program?
     – The infrastructure (system software or middleware)?




                                                       7
   Distributed Collaboration
– Key enabler: Typed Interfaces
  • Makes it possible for system software (or
    application software) to automatically and reliably
    perform
     – 1. Parameter marshalling
     – 2. Control dispatch

– Key enabler: Type safety
  • Makes it possible to
     – Manage error-avoidance
     – Manage complexity

  • Enabled by Typed Interfaces                   8
    Distributed Collaboration
– Some new issues of distributed, versus local,
  collaboration
  • Heterogeneity - a certainty
  • De-coupling - more parties involved
  • Scalability - adds complexity
  • Network latency - a certainty
  • Network resources - such as connections
  • Error handling - is it down, or still processing?


                                                        9
                   Distributed Collaboration
            • Revolutionary ideas in Java RMI:
                   • Pass-by-value and class loading
                 – Example: Universal currency converter (UCC)
1. Ask
Server S1           Client                        UCC                UCC
for a copy of
Server S2.          object                       Factory Creates   instance
                                                  object
                    (Java)

2. Server S1
returns a           Client                        UCC                UCC
copy of                          UCC
Server S2.          object     instance          Factory           instance
                                 copy             object
                    (Java)

3. Client
talks to copy       Client                                           UCC
of S2 locally.                   UCC              UCC
                    object     instance          Factory           instance
                    (Java)       copy             object
                                                                       10
 The Evolution of Distributed Collaboration
• 1st Generation: Data Communications
   – “DATACOMM”: (the data gets distributed)
      • the transport of data across the wire
      • shared files, sockets, FTP, TCP, UDP
• 2nd Generation: Remote Procedure Middleware
   – “RPM”: (the thread gets distributed)
       • program jump across the wire - virtual distributed thread
       • DCE RPCs
• 3rd Generation: Distributed Objects
   – “DOT”: (the objects gets distributed)
      • object invocation across the wire
      • CORBA, DCOM
• 4th Generation: Distributed Object Webs
   – “DOW”: (structured collections of objects get distributed)
      • Java RMI, JiniTM technology - enabled by Class loading
                                                             11
        and Pass-by-Value
Four Generations of Local and
  Distributed Collaboration

        “There’s a pattern.”




                               12
  Generations of Collaboration
– Making a distinction between distributed
  collaboration and data transfer
  • The idea of data transfer is that...
     – Two applications are separated by a the network
     – They send data to each other across the network

  • The idea of distributed collaboration is that
     – An application (the enterprise) runs on a network
     – Its objects collaborate with each other the same way
       that they would if it ran on a single computer
     – Local patterns often apply across the network also.
     – This makes sense because…
                                                    13
         » “the network is the computerT”
     Generations of Collaboration
– 1st Gen Local: Pre-modular collaboration
  • The Blob
     – In the early days (e.g. FORTRAN II) there were
        » No modules (procedures, subprograms, etc.)
     – There was only The Blob:
        » “Note hidden behind a rock” collaboration
        » Shared disk area or memory buffer

– 1st Gen Distributed: Data Communications
  • Data transfer
  • The Blob was passed as a network message
                                                        14
     Generations of Collaboration
– 1st Gen Local and Distributed
  • The Blob feature analysis
     – Requester had to know how to encode the request
     – “Request” sent to location, not service
     – Responder had to know
         » when to look to get request
         » how to decode (parse) the request
         » how to figure out what action to perform
         » whether to return a response
         » to return a response

                                                      15
     Generations of Collaboration
– 1st Gen Local and Distributed: Evaluation
  • Required more programming:
     – All control dispatch and parameter marshalling left to the
       application programmer

  • Result: No typed interfaces or type-safety
     – more application code
     – not extensible
     – not re-usable
     – not interchangeable
     – error-prone
     – not resilient
                                                          16
     Generations of Collaboration
– 2nd Gen Local: Modular collaboration
  • Program calls: type-safe
     – Functions, subroutines, subprograms, procedures
     – Named modules - invocation points
     – Callable at runtime
     – Related data passed as arguments and return values

  • System software handles
     – Control dispatch
     – Parameter marshalling

– 2nd Gen Distributed: RPCs
                                                         17
  • Function call over the network
     Generations of Collaboration
– 2nd Gen Local and Distributed: Evaluation
  • Positives
     – Improved ease-of-use
         » Service names grouped with related, typed data
     – Reduced application programming
         » Parameter marshalling performed by the system
     – Error-resistant
         » Compile-time signature and type checking
         » Drastically reduced parsing logic errors



                                                       18
     Generations of Collaboration
– 2nd Gen Local and Distributed: Evaluation
  • Negatives
     – Still too complex
         » Too many services in one grouping (the whole app)
     – Services not sufficiently supportable
         » Service can change unrelated data
         » Single fixes to server can break server or client
     – Services not sufficiently extensible
         » Can’t add features without changing existing code
     – Services not sufficiently interchangeable
         » Can’t plug and play alternative offerings without
                                                           19
           changing lots of code - many large switch statements
     Generations of Collaboration
– 2nd Gen Local and Distributed: Evaluation
  • Negatives
     – Problem Analysis
         » 1. Too little cohesion within modules
         » 2. Too much coupling among modules

  • How to fix it
     – develop a programming paradigm that
         » 1. Improves module cohesion
         » 2. Reduces inter-module coupling


                                                   20
     Generations of Collaboration
– 3rd Gen Local: Classical OO Collaboration
  • Solution: Provide new mechanisms to improve
     – intra-module cohesion
     – inter-module de-coupling

  • New OO mechanisms:
        » Typed interfaces

        » Separation of interface from implementation

        » Encapsulation

        » Data-hiding

        » Implementation inheritance

        » Interface inheritance

        » Polymorphism                                  21
          Generations of Collaboration
– 3rd Gen Local: Classical OO Collaboration
   • Analysis

 OO Feature         Ease-    Complexity   Supportability   Extensibil   Reusability   Interchange-
                    of-use   Management                    -ity                       ability
 Typed Interfaces   Yes      Yes          Yes
 Separation of               Yes          Yes              Yes                        Yes
 Interface and
 Implementation
 Encapsulation               Yes          Yes
 Implementation              Yes          Yes              Yes          Yes
 Inheritance
 Interface                                                 Yes          Yes           Yes
 Inheritance
 Polymorphism                                              Yes          Yes           Yes




                                                                                            22
     Generations of Collaboration
– 3rd Gen Local: Classical OO Collaboration
  • Classical OO Feature evaluation
     – Has all benefits of previous generations (module
       collaboration)
     – intra-module cohesion and de-coupling
     – Yields superior management of
         » Ease-of-use, Complexity, Supportability, Extensibility,
           Interchangeability

     – Elegantly solves Negatives of previous generation

– 3rd Gen Distributed: Distributed Objects
  • CORBA, COM/DCOM
  • Similar evaluation                                               23
     Generations of Collaboration

– 3rd Gen Distributed Objects: Evaluation
  • Negatives
     – CORBA limitations result in only supporting large-grained
       design
     – This resulted in CORBA object models containing only
       large grained designs
     – Therefore, you couldn’t do a distributed object model of
       your entire system
     – (However, CORBA is good for integrating systems that
       are independently designed.)



                                                          24
  Generations of Collaboration
– 3rd Gen Local: Distributed Object
  • Reason?
     – Objects cannot be passed-by-value
     – This would enable fine-grained distributed object
       models
     – And, therefore, generalized object models

  • How to fix?
     – Add pass-by-value
     – Which requires dynamic, cross-network class loading




                                                     25
  Generations of Collaboration
– 4th Gen Local: Distributed Object Webs
  • Leverages pass-by-value and class loading to
    enable a distributed object model of your entire
    system
  • Enables the use of best practices of OO to
    distributed computing
     – architecture and design reuse, encapsulation,
       inheritance, polymorphism, etc.

  • Java RMI
  • Promotes an industry of
     – Distributed frameworks and components
         » EJBTM, CORBA components
                                                       26
         » Jini, JavaSpacesTM
    Generations of Collaboration
– Three Generations of XML
     – Déjà vu (previous generations repeated)
     – Time-scale compressed: 3 years

  • 1st Generation: XML over HTTP
     – data transfer (and the Blob) rides again

  • 2nd Generation: XML-RPC
     – RPCs ride again

  • 3rd Generation: SOAP
     – An “Object-oriented XML-RPC”
     – An XML-based transport protocol
         » to be used internally by CORBA and COM   27
      Generations of Collaboration
              J2EE and the 4 Generations

• 1st Gen: Data Communications (Yes)
   – HTTP, JMS
• 2nd Gen: Remote Procedure Calls (Yes)
   – XML-RPC/HTTP
• 3rd Gen: Distributed Objects (Yes - primarily)
   – RMI, CORBA
   – JMS (almost - with object payloads)
   – SOAP (with Apache RPCRouter servlet)
• 4th Gen: Distributed Object Webs (Yes - primarily)
   – RMI

                                                   28
What About Loose
   Coupling?




                   29
          Loose Coupling?
• Some popular uses of the phrase “loose
  coupling”
  – 1. The object-oriented sense of “de-
    coupling”
  – 2. No well-defined interfaces
    • (AKA “the Blob interface”)
  – 3. Client has a “contract” with an
    intermediary (e.g. message server)
    • rather than with directly its collaborator(s)


                                                      30
          Loose Coupling?
• Sense #1: The object-oriented notion of
  de-coupling
  – Enables encapsulation and polymorphism
  – Is strongly enabled in OO by
     • Separation of interface from implementation
     • Well-defined interfaces
     • Provides OO with it’s “plug-ability”
  – This is provided by 2nd Generation
     • RMI and CORBA


                                                31
            Loose Coupling?
• Sense #1: The object-oriented notion of
  de-coupling
  – Provides “rich” API features:
     •   Ease-of-development (no parsing)
     •   Extensibility (inheritance)
     •   Supportability (type safety)
     •   Interchangeability (polymorphism)
     •   Reusability
  – De-coupling often provides the features that
    are often sought through “loose coupling”.

                                             32
         Loose Coupling?
• Sense #2: No well-defined interfaces
  – The blob
  – Often promoted by “data transfer”
    interoperability approaches
  – The problem:
    • Both client and server apps must perform
      parameter marshalling
    • Server app must perform control dispatch
    • The middleware should be doing this
    • Requires more coding - breaks when interface
      changes
  – This fits XML/HTTP, blob/JMS             33
           Loose Coupling?
• Sense #2: No well-defined interfaces
  – This approach tosses away OO’s prime
    features and benefits...
  – By generally exacerbating
    •   Ease-of-development (needless parsing)
    •   Extensibility (no inheritance)
    •   Supportability (poor type safety)
    •   Interchangeability (no polymorphism)
    •   Reusability (of code)



                                                 34
          Loose Coupling?
• Sense #3: Client has contract with
  intermediary - rather than with
  collaborator(s)
  – Sometimes this is what is needed.
     • E.g. when collaborator sessions are not
       synchronized (collaborator availability)
  – This fits JMS
  – What you may give up
     • Collaborators may not be able to expose well-
       defined (type-safe) contracts to their fellow
       collaborators
     • But, procedure call semantics with collaborators
       would be possible, if JMS spec provided it35
          Loose Coupling?
• Sense #3: Client has contract with
  intermediary - rather than with
  collaborator(s)
  – Observation
     • These two are independent and need not be
       linked as they are in today’s middleware:
        – Synchrony (synch vs. asynch)
        – Procedure call semantics
     • “Therefore, procedure call semantics (with
       collaborators) in JMS would be possible, if the
       spec provided for it


                                                 36
           Loose Coupling?
• Conclusion
  – Transporting unparsed data messages is OK
  – Just be aware that
     • They are not type-safe
     • Application must perform parameter marshalling
     • Application performs control dispatch
  – This can lead to difficulties with
     • Extra coding in the application
     • Error-proneness
     • Extensibility

                                                  37
            Loose Coupling?
• Conclusion
  – Danger: Type-safety and related features
     •   interfaces
     •   encapsulation
     •   subtypes
     •   polymorphism
  – are often be forgotten in the rush to do “loose-
    coupling”.
• It is possible to have both loose-coupling
  and type safety
                                                38
 Understanding
Communications
  Middleware


                 39
   Understanding Middleware


• Example J2EE middleware
  –   Java RMI
  –   Java IDL
  –   Other CORBA Orbs
  –   JMS topics
  –   JMS point-to-point


• Not examples of middleware
  – XML/HTTP with DOM and SAX
  – SOAP
  – IIOP                        40
          Understanding Middleware
• Middleware provides transport for
  distributed interoperability
• Any middleware type supports
  – 1. a programming interface (API)
  – 2. a transport protocol (aka “wire” protocol)
• Naming convention
  – <programming interface>/<transport protocol>
  – Examples
     •   IDL/IIOP
     •   RMI/JRMP
     •   RMI/IIOP                              41
     •   IDL/SOAP
         Understanding Middleware
   • Anatomy of a Middleware Type

                            Application


                 middleware programming interface (API)

                       middleware implementation
                           •control dispatch
Middleware                 •parameter marshalling
  Layer                    •message encoding
                           •message transport


                      middleware transport protocol



               Next Layer interface (e.g. sockets)        42
         Understanding Middleware
   • Example Middleware Type: Java RMI

                             Java Application


                        Java RMI programming interface

                           Java RMI implementation
                               •control dispatch
 Java RMI                      •parameter marshalling
Middleware                     •message encoding
                               •message transport


             Java Remote Method Protocol (JRMP) transport protocol



                               TCP Sockets                     43
                Understanding Middleware
      • Example: HTTP with XML

                              Java Application
                             •control dispatch
                             •parameter marshalling




                     java.net.URL class programming interface
   HTTP is not
  “Middleware”             java.net.URL implementation
                                •message encoding
     HTTP is                    •message transport
transport protocol
      only!                 HTTP transport protocol



                                TCP Sockets                     44
         Understanding Middleware

• De-coupling of characteristics
  – For a given middleware type
     • The characteristics of its programming interface
     • may differ from
     • the characteristics of its transport protocol.
  – I.e., middleware de-couples API from protocol




                                                     45
         Understanding Middleware
   • Inventing New Middleware Types
   • Example: Java RMI/SOAP

                       Java Application

                   Java RMI programming interface

                      Java RMI implementation
 Java RMI                •control dispatch
Middleware               •parameter marshalling
                         •message encoding
                         •message transport


                      SOAP transport protocol



                              HTTP                  46
A Model of Distributed
 Collaboration Styles




                         47
                     The Model
– Possible interaction characteristics
  • An interaction among collaborating distributed
    modules involves
     – sender
         » “requestor”, “client”,...
     – receiver(s)
         » “provider”, “server”, “servant”,...
     – a message

  • Senders and receivers can have various
    relationships to each other…
  • As defined by the answers to certain questions.
                                                 48
                   The Model
– Possible interaction characteristics
  • As defined by the answers to these questions:
     – 1. Must the sender and receiver(s) be available
       simultaneously?
     – 2. Can the message have multiple receivers?
     – 3. Is the message destination a receiver, or a location?
     – 4. Is parameter marshalling and control dispatch handled
       by the middleware, or the application?
     – 5. Does the message transfer represent an execution
       control transfer to the receiver module?
     – 6. What kind of response, if any, does the sender expect
       from the receiver?
     – 7. What kind of recovery capabilities are provided?


                                                        49
                          The Model
– Distributed Collaboration Style
   • Organizing these questions

               Seven categories of DC Characteristics

Characteristic Category   Addresses this question
Collaborator coupling     Must the sender and receiver(s) be available
                          simultaneously?
Receiver count            Can a message have multiple receivers?
Recipient designation     Is the message destination a receiver, or a location?
Marshalling               Is parameter marshalling and handled by the middleware,
                          or the application?
Execution transfer        Does the message transfer represent an execution
                          control transfer to the receiver module?
Response handling         What kind of response, if any, does the sender expect
                          from the receiver?
Recovery handling         What kind of recovery capabilities are provided?

                                                                         50
                   The Model
– Requirements-driven selection
  • Each project should decide how to answer each of
    these questions, based on its requirements
  • Rather than deciding based on...
     – Wanting to use what you already know
     – Wanting to use something new and trendy
     – Wanting to improve your resume
     – Wanting to use something cool
     – Wanting to solve performance qualities at the expense of
       functionality qualities
     – etc.
  • These requirements are captured as the answers
    to the above questions for each collaboration
    instance of your project                      51
                        The Model
     7-dimensional Vector used to describe any DC type



• A DC Style: any way of populating this vector
• Use project collaboration requirements to populate a vector




   Characteristic Category   Possible values for this category for a DC type
   Collaborator coupling
   Receiver count
   Recipient designation
   Marshalling
   Execution transfer
   Response handling
   Recovery handling
                                                                       52
                        The Model
     7-dimensional Vector used to describe any DC type



• A 7-dimensional space of all possible DC Styles
• This 7-dimensional space is a sparse matrix



   Characteristic Category   Possible values for this category for a DC type
   Collaborator coupling
   Receiver count
   Recipient designation
   Marshalling
   Execution transfer
   Response handling
   Recovery handling
                                                                       53
                          The Model
Characteristic       Possible values for each category
Category
Collaborator            Direct
coupling                Indirect
Receiver count          Exactly 1
                        1-to-many
Recipient               Exposed location
designation             Controlled location
                        Recipient
Marshalling             Application parses unformatted buffer
                        Application parses structured buffer
                        Middleware marshals primitive data
                        Middleware marshals structured data
                        Middleware marshals executable objects
                        Middleware marshals object references

Execution transfer      Data transfer only
                        Execution control transfer
                        Transfer of executable code
Response handling       No response
                        Immediate (blocking) response
                        Polled response
                        Notified response
Recovery handling       Error status returns
                        System Exception handling
                        User Exception handling                  54
                        Distributed transaction support
Collaboration Styles in
 J2EE Applications




                          55
       Understanding Middleware


• Example J2EE middleware
  –   XML/HTTP with DOM/SAX
  –   JMS topics
  –   JMS point-to-point
  –   JavaIDL and other CORBA Orbs
  –   Java RMI
  –   SOAP - under Apache Tomcat RPC Router
  –   SOAP - under a CORBA Orb




                                              56
Selecting the Appropriate J2EE Middleware
        XML/HTTP with DOM and SAX DC Characteristics
Characteristic       Possible values for each category
Category
Collaborator            Direct
coupling
Receiver count          Exactly 1
Recipient               Recipient
designation
Marshalling             Application parses structured buffer
Execution transfer      Data transfer only
Response handling       Immediate (blocking) response
Recovery handling       Error status returns


    •   Software freely available
    •   Recipient requires a web server (servlet, JSP, etc.).
    •   Both sender and receiver write lots of parsing code
    •   Receiver provides control dispatch, if any
    •   Doesn’t leverage advantages of type-safe interfaces
    •   A data transport mechanism                              57
Selecting the Appropriate J2EE Middleware

 • JMS - two styles
    – Point-to-point
       •   message queuing
       •   asynch, but synch is an option
       •   pull, but push is an option
       •   many consumers, one per message
    – Topics
       •   publish and subscribe
       •   promotes “event notification” model
       •   many consumers per message supported
       •   good for broadcasting
                                                  58
Selecting the Appropriate J2EE Middleware
                 JMS point-to-point DC Characteristics
Category             Characteristics
Collaborator            Indirect
coupling
Receiver count          One-to-many
Recipient               Controlled location (queue)
designation
Marshalling             Unformatted buffer – application does parsing
                        Formatted structure – application is assisted in parsing
                        Serialized object - application is assisted in parsing
Execution transfer      Data transfer only
Response handling       No response
                        Immediate (blocking) response
                        Polled response
                        Notified response
Recovery handling       System Exception handling
                        Distributed transaction support


  •   Good for workflow process models
  •   Can be synchronous or asynchronous
  •   Contract is with MOM, not recipient
  •   Producers and consumers may write considerable parsing code
                                                              59
  •   A data transport mechanism
Selecting the Appropriate J2EE Middleware
                     JMS topics DC Characteristics
Category             Characteristics
Collaborator            Indirect
coupling
Receiver count          One-to-many
Recipient               Controlled location (topic)
designation
Marshalling             Unformatted buffer – application does parsing
                        Formatted structure – application is assisted in parsing
                        Serialized object - application is assisted in parsing
Execution transfer      Data transfer only
Response handling       No response
                        Immediate (blocking) response
                        Polled response
                        Notified response
Recovery handling       System Exception handling
                        Distributed transaction support

•   Can be used for broadcasting
•   Good for event-driven, asynchronous process models
•   Contract is with MOM, not recipient
•   Producers and consumers may write considerable parsing code
                                                             60
•   A data transport mechanism
Selecting the Appropriate J2EE Middleware
 • CORBA
    –   Distributed OO
    –   Method calls directly to remote objects
    –   Mixed programming languages
    –   Parameters can be
         • primitive and structured variables
         • refs to remote objects
         • pass-by-value usually very difficult
    – OO technology supported
         •   encapsulation
         •   interface inheritance
         •   1/2 polymorphism
                                                  61
         •   exceptions
 Selecting the Appropriate J2EE Middleware
                     CORBA Orb DC Characteristics
Characteristic       Possible values for each category
Category
Collaborator            Direct
coupling
Receiver count          Exactly 1
Recipient               Recipient
designation
Marshalling             Middleware marshals primitive data
                        Middleware marshals structured data
                        Middleware marshals executable objects
                        Middleware marshals object references
Execution transfer      Execution control transfer
                        Transfer of executable code (with difficulty)
Response handling       No response
                        Immediate (blocking) response
                        Polled response
                        Notified response
Recovery handling       System Exception handling
                        User Exception handling
                        Distributed transaction support

  •   Synchronous Request/reply
  •   “Virtual distributed threads” (3rd generation DC)
  •   Has option for asynchronous events
  •   Has the advantages of type-safe OO programming             62
  •   OO: encapsulation, reference polymorphism, I/F inheritance
Selecting the Appropriate J2EE Middleware
 • Java RMI
    –   Distributed OO
    –   Method calls directly to remote objects
    –   Java only
    –   Parameters can be
         • primitive and structured variables
         • refs to remote objects
         • full pass-by-value - easy and powerful
    – OO technology supported
         •   encapsulation
         •   interface inheritance
         •   full polymorphism                      63
         •   exceptions
Selecting the Appropriate J2EE Middleware
                 Java RMI DC Characteristics
Characteristic       Possible values for each category
Category
Collaborator            Direct
coupling
Receiver count          Exactly 1
Recipient               Recipient
designation
Marshalling             Middleware marshals primitive data
                        Middleware marshals structured data
                        Middleware marshals executable objects
                        Middleware marshals object references
Execution transfer      Execution control transfer
                        Transfer of executable code
Response handling       Immediate (blocking) response
Recovery handling       System Exception handling
                        User Exception handling
                        Distributed transaction support

•   Synchronous Request/reply
•   “Virtual distributed threads”
•   “Distributed Object Webs” (4th generation DC)
•   Has the advantages of type-safety                         64
•   OO: encapsulation, complete polymorphism, I/F inheritance
Selecting the Appropriate J2EE Middleware
                           SOAP

  • SOAP is a transport protocol, not a middleware API
  • Programmers are not expected to use SOAP directly
  • SOAP is intended to be encapsulated inside of an API such
    as CORBA IDL or COM IDL
      – Orb vendors and Microsoft are busy doing that now
  • SOAP uses XML internally as an encoding scheme
      – just like IIOP uses CDR internally
      – just like DCOM uses XDR internally
  • Programmers who use SOAP are never expected to see any
    XML documents
  • SOAP is not needed to transport XML documents
      – You can do that with sockets or HTTP



                                                            65
Selecting the Appropriate J2EE Middleware
                 Apache Tomcat RPC Router Orb
                  Using SOAP transport protocol
                       DC Characteristics
Characteristic       Possible values for each category
Category
Collaborator            Direct
coupling
Receiver count          1-to-many (possibly chained receivers)
Recipient               Recipient
designation
Marshalling             Not typesafe
                        Middleware marshals primitive data
                        Middleware marshals compound primitive data
                        Middleware marshals structured data
Execution transfer      Execution control transfer
Response handling       Immediate (blocking) response
Recovery handling       Error status returns


    • Software freely available, requires a servlet engine
    • “Virtual distributed threads”
    • Supports typed interfaces, but not type-safe
                                                                       66
Selecting the Appropriate J2EE Middleware
                              CORBA Orb
                     Using SOAP transport protocol
                           (rather than IIOP)
                          DC Characteristics
Characteristic       Possible values for each category
Category
Collaborator            Direct
coupling
Receiver count          Exactly 1
Recipient               Recipient
designation
Marshalling             Middleware marshals primitive data
                        Middleware marshals structured data
                        Middleware marshals executable objects
                        Middleware marshals object references
Execution transfer      Execution control transfer
                        Transfer of executable code (with difficulty)
Response handling       No response
                        Immediate (blocking) response
                        Polled response
                        Notified response
Recovery handling       System Exception handling
                        User Exception handling
                        Distributed transaction support

    • Exactly the same characteristics as CORBA over IIOP
    • Orbs are planning on using SOAP and IIOP internally                67
Selecting the Appropriate J2EE Middleware

                             J2EE Middleware

   External                                   Business            Enterprise
                         Web Tier
    Clients                                    Tier              Information
                                                                     Tier

                       Serv-let,           RMI
                        JSPTM,
                                    RMI
  XML/HTTP           JavaBean TM           Entity
                     components             and          RMI
xxx/SOAP/HTTP                       JMS    Session
                                            EJBs         IDL

              RMI/IIOP                                   JMS
          CORBA/IIOP
                                          JMS RMI        XML/HTTP

                     JMS                  Message-
                                                         xxx/SOAP/HTTP
                                           Driven
                                           EJBs
                                                                     68
  Selecting the Best
Collaboration Styles for
  J2EE Applications


                           69
   Steps to Selecting the
   Appropriate DC style
– 1. Identify your required distributed
  collaboration style
– 2. Develop a vector to describe it
– 3. Develop vectors to describe various
  J2EE middleware options
– 4. Select the J2EE middleware option with
  the closest match
– 5. If no matches are sufficiently close,
  maybe develop your own with the desired
  characteristics.                         70
The Scalability Model




                        71
           The Scalability Model

• Seven domains of scale:
  –   7. Global architecture
  –   6. Enterprise architecture
  –   5. System architecture
  –   4. Application architecture
  –   3. Frameworks
  –   2. Design Patterns
  –   1. Classes and objects


                                    72
              The Scalability Model

• J2EE and the Scalability Model
  – By definition, J2EE spans
     • from level 1 (Classes and objects)
     • to level 4 (Application architecture)
  – But, at a given site, J2EE can span
     • all the way to level 6 (Enterprise architecture)
  – Across certain businesses, it can span
     • all the way to level 7 (Global architecture)



                                                          73
             The Scalability Model

• Scalability Model
  – Different design dynamics based on scale
• For example,
  – It might make sense to exchange XML
    documents between two business enterprises
    (B2B)…
  – Why?
     • Both businesses may not be using compatible
       technologies
     • Sender shouldn’t be aware of receiver’s processing

                                                    74
              The Scalability Model
• Scalability Model
  – But, do you want all of your local classes to
    have only one method that takes only one
    parameter - a String containing an XML
    document??
  – Of course not.
  – Why not?
     • Loss of all type-related and OO advantages
     • Calling an XML parser for every call to costly
     • Large switch statements for control dispatch
        – error-prone
        – expensive to support
                                                        75
        – expensive to extend
         The Scalability Model

• Rich API Features - reiterated
  – Reduced application code
  – Extensibility
  – Supportability
  – Reusability
  – Interchangeability
• Encouraged by strong typing and OO


                                   76
                 The Scalability Model
• Tensions and Forces
               High

                       Java RMI
                             CORBA IDL
                      Object Collaboration
    Rich
    API
    Features                                  JMS




                                                             XML/HTTP
                                             Data Transfer
                                                                  High
         Low                       Transport Protocol Compatibility

                                                                        77
         The Scalability Model

• In higher domains of scal
  – API feature richness must often be
    sacrificed in favor of compatibility
• In lower domains of scale
  – compatibility is built into the platform
  – rich API features can be considered
• Standardization feature-richness in all
  domains




                                               78
Conclusions




              79
                Conclusions
  Selecting the best J2EE collaboration style

– Requirements-Driven Selection
  • 1. Develop middleware option vectors to describe
    candidate J2EE middleware options
  • 2. Develop a requirements vector for each
    collaboration in your application
  • 4. For each collaboration, select the J2EE
    middleware option whose vector matches most
    closely the requirements vector
  • 5. Sacrifice this selection if compatibility issues
    demand it
                                                 80
       Selecting the Best
Distributed Collaboration Styles
              for a
       J2EE Application


           Grant Holland
       Senior Java Architect
      Sun Microsystems, Inc.
      grant.holland@sun.com
          March 28, 2001
                                   81

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:10/1/2011
language:English
pages:81