Selecting the Best Distributed Collaboration Styles for a J2EE TM Application

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