1 / 81

Selecting the Best Distributed Collaboration Styles for a J2EE TM Application

Selecting the Best Distributed Collaboration Styles for a J2EE TM Application. O’Reilly Conference on Enterprise Java Wednesday, March 28, 2001. Grant Holland Senior Java Architect Sun Java Center. Purpose.

Download Presentation

Selecting the Best Distributed Collaboration Styles for a J2EE TM Application

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Selecting the BestDistributed Collaboration Stylesfor aJ2EETM Application O’ReillyConference on Enterprise JavaWednesday, March 28, 2001 Grant HollandSenior Java ArchitectSun Java Center

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

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

  4. Distributed Collaboration “The network is the computerTM”

  5. DistributedCollaboration • 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).

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

  7. DistributedCollaboration • The question is… • Who is going to handle all of this… • the application program? • The infrastructure (system software or middleware)?

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

  9. DistributedCollaboration • 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?

  10. DistributedCollaboration • Revolutionary ideas in Java RMI: • Pass-by-value and class loading • Example: Universal currency converter (UCC) 1. Ask Server S1 for a copy of Server S2. Creates Client object(Java) UCC Factory object UCC instance 2. Server S1 returns a copy of Server S2. Client object(Java) UCC Factory object UCC instance UCC instance copy 3. Client talks to copy of S2 locally. Client object(Java) UCC instance UCC Factory object UCC instance copy

  11. 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 and Pass-by-Value

  12. Four Generations of Local and Distributed Collaboration“There’s a pattern.”

  13. 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… • “the network is the computerT”

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

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

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

  17. 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 • Function call over the network

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

  19. 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 changing lots of code - many large switch statements

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

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

  22. Generations of Collaboration • 3rd Gen Local: Classical OO Collaboration • Analysis

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

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

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

  26. 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 • Jini, JavaSpacesTM

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

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

  29. What About Loose Coupling?

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

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

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

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

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

  35. 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 it

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

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

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

  39. Understanding CommunicationsMiddleware

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

  41. 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 • IDL/SOAP

  42. Understanding Middleware • Anatomy of a Middleware Type Application middleware programming interface (API) middleware implementation • control dispatch • parameter marshalling • message encoding • message transport Middleware Layer middleware transport protocol Next Layer interface (e.g. sockets)

  43. Understanding Middleware • Example Middleware Type: Java RMI Java Application Java RMI programming interface Java RMI implementation • control dispatch • parameter marshalling • message encoding • message transport Java RMI Middleware Java Remote Method Protocol (JRMP) transport protocol TCP Sockets

  44. Understanding Middleware • Example: HTTP with XML Java Application • control dispatch • parameter marshalling java.net.URL class programming interface HTTP is not “Middleware” HTTP is transport protocol only! java.net.URL implementation • message encoding • message transport HTTP transport protocol TCP Sockets

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

  46. Understanding Middleware • Inventing New Middleware Types • Example: Java RMI/SOAP Java Application Java RMI programming interface Java RMI implementation Java RMI Middleware • control dispatch • parameter marshalling • message encoding • message transport SOAP transport protocol HTTP

  47. A Model of Distributed Collaboration Styles

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

  49. 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?

  50. The Model • Distributed Collaboration Style • Organizing these questions Seven categories of DC Characteristics

More Related