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

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

3. 3 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 J2EE TM Applications Selecting the Best Collaboration Styles for a J2EE Application Conclusions

4. 4 Distributed Collaboration The network is the computer TM

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

6. 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. 7 Distributed Collaboration –The question is… Who is going to handle all of this… –the application program? –The infrastructure (system software or middleware)?

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

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

11. 11 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, Jini TM technology - enabled by Class loading and Pass-by-Value The Evolution of Distributed Collaboration

12. 12 Four Generations of Local and Distributed Collaboration Theres a pattern.

13. 13 –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 computer T Generations of Collaboration

14. 14 –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 Generations of Collaboration

15. 15 –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 Generations of Collaboration

16. 16 –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 Generations of Collaboration

17. 17 –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 Generations of Collaboration

18. 18 –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 Generations of Collaboration

19. 19 –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 »Cant add features without changing existing code –Services not sufficiently interchangeable »Cant plug and play alternative offerings without changing lots of code - many large switch statements Generations of Collaboration

20. 20 –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 Generations of Collaboration

21. 21 –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 Generations of Collaboration

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

23. 23 –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 Generations of Collaboration

24. 24 –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 couldnt do a distributed object model of your entire system –(However, CORBA is good for integrating systems that are independently designed.) Generations of Collaboration

25. 25 –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 Generations of Collaboration

26. 26 –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 »EJB TM, CORBA components »Jini, JavaSpaces TM Generations of Collaboration

27. 27 –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 Generations of Collaboration

28. 28 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 Generations of Collaboration J2EE and the 4 Generations

29. 29 What About Loose Coupling?

30. 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. 31 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 its plug-ability –This is provided by 2nd Generation RMI and CORBA Loose Coupling?

32. 32 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. Loose Coupling?

33. 33 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 Loose Coupling?

34. 34 Sense #2: No well-defined interfaces –This approach tosses away OOs 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) Loose Coupling?

35. 35 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 Loose Coupling?

36. 36 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 todays 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 Loose Coupling?

37. 37 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 Loose Coupling?

38. 38 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 Loose Coupling?

39. 39 Understanding Communications Middleware

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

41. 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 – / –Examples IDL/IIOP RMI/JRMP RMI/IIOP IDL/SOAP

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

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

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

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

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

47. 47 A Model of Distributed Collaboration Styles

48. 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. 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. 50 Seven categories of DC Characteristics The Model –Distributed Collaboration Style Organizing these questions

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

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

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

54. 54 The Model

55. 55 Collaboration Styles in J2EE Applications

56. 56 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 Understanding Middleware

57. 57 XML/HTTP with DOM and SAX DC Characteristics Selecting the Appropriate J2EE Middleware 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 Doesnt leverage advantages of type-safe interfaces A data transport mechanism

58. 58 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 Selecting the Appropriate J2EE Middleware

59. 59 JMS point-to-point DC Characteristics Selecting the Appropriate J2EE Middleware Good for workflow process models Can be synchronous or asynchronous Contract is with MOM, not recipient Producers and consumers may write considerable parsing code A data transport mechanism

60. 60 JMS topics DC Characteristics Selecting the Appropriate J2EE Middleware 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 A data transport mechanism

61. 61 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 exceptions Selecting the Appropriate J2EE Middleware

62. 62 CORBA Orb DC Characteristics Selecting the Appropriate J2EE Middleware Synchronous Request/reply Virtual distributed threads (3rd generation DC) Has option for asynchronous events Has the advantages of type-safe OO programming OO: encapsulation, reference polymorphism, I/F inheritance

63. 63 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 exceptions Selecting the Appropriate J2EE Middleware

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

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

66. 66 Selecting the Appropriate J2EE Middleware Apache Tomcat RPC Router Orb Using SOAP transport protocol DC Characteristics Software freely available, requires a servlet engine Virtual distributed threads Supports typed interfaces, but not type-safe

67. 67 Selecting the Appropriate J2EE Middleware CORBA Orb Using SOAP transport protocol (rather than IIOP) DC Characteristics Exactly the same characteristics as CORBA over IIOP Orbs are planning on using SOAP and IIOP internally

68. 68 Entity and Session EJBs Enterprise Information Tier External Clients Business Tier Serv-let, JSP TM, JavaBean TM components RMI/IIOP XML/HTTP Web Tier Message- Driven EJBs JMS RMI JMS RMI JMS CORBA/IIOP RMI IDL JMS xxx/SOAP/HTTP RMI J2EE Middleware XML/HTTP xxx/SOAP/HTTP Selecting the Appropriate J2EE Middleware

69. 69 Selecting the Best Collaboration Styles for J2EE Applications

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

71. 71 The Scalability Model

72. 72 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 The Scalability Model

73. 73 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) The Scalability Model

74. 74 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 shouldnt be aware of receivers processing The Scalability Model

75. 75 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 –expensive to extend The Scalability Model

76. 76 Rich API Features - reiterated –Reduced application code –Extensibility –Supportability –Reusability –Interchangeability Encouraged by strong typing and OO The Scalability Model

77. 77 Tensions and Forces The Scalability Model Transport Protocol Compatibility Rich API Features Low High Java RMI CORBA IDL JMS XML/HTTP Object Collaboration Data Transfer

78. 78 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 The Scalability Model

79. 79 Conclusions

80. 80 Conclusions –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 Selecting the best J2EE collaboration style

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