1 Selecting the Best Distributed Collaboration Styles for a J2EE TM Application Grant Holland Senior Java Architect Sun Java Center OReilly Conference

1

Selecting the BestDistributed Collaboration Styles

for a

J2EETM Application

Grant HollandSenior Java Architect

Sun Java Center

O’ReillyConference on Enterprise Java

Wednesday, March 28, 2001

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

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


– 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


– The question is…

• Who is going to handle all of this…

– the application program?

– The infrastructure (system software or middleware)?

8


– 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


– 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

• 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

UCC instance

copy


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, JiniTM technology - enabled by Class loading and Pass-by-Value

The Evolution of Distributed Collaboration

12

Four Generations of Local and Distributed Collaboration

“There’s a pattern.”

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 computerT”

Generations of Collaboration

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


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


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


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


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


19


• 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


• 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

– 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


• Analysis

OO Feature Ease-of-use

ComplexityManagement

Supportability Extensibil-ity

Reusability Interchange-ability

Typed Interfaces Yes Yes YesSeparation ofInterface andImplementation

Yes Yes Yes Yes

Encapsulation Yes YesImplementationInheritance

Yes Yes Yes Yes

InterfaceInheritance

Yes Yes Yes

Polymorphism Yes Yes Yes


23


• 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

– 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

– 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

– 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

– 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

• 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


J2EE and the 4 Generations

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

• 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

Loose Coupling?

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

• 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

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

Loose Coupling?

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

• 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

Loose Coupling?

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

• 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

Understanding Communications

Middleware

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


• 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

Application

middleware programming interface (API)

middleware implementation

Next Layer interface (e.g. sockets)

middleware transport protocol

MiddlewareLayer

• Anatomy of a Middleware Type


•control dispatch•parameter marshalling•message encoding•message transport

43

Java Application

Java RMI programming interface

Java RMI implementation

TCP Sockets

Java Remote Method Protocol (JRMP) transport protocol

Java RMIMiddleware

• Example Middleware Type: Java RMI



44

Java Application

java.net.URL class programming interface

java.net.URL implementation

TCP Sockets

HTTP transport protocol

HTTP is not“Middleware”

HTTP istransport protocol

only!

• Example: HTTP with XML


•message encoding•message transport

•control dispatch•parameter marshalling

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


46

Java Application

Java RMI programming interface

Java RMI implementation

HTTP

SOAP transport protocol

Java RMIMiddleware

• Inventing New Middleware Types

• Example: Java RMI/SOAP



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

Seven categories of DC Characteristics

The Model– Distributed Collaboration Style

• Organizing these questions

Characteristic Category Addresses this question

Collaborator coupling Must the sender and receiver(s) be availablesimultaneously?

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?

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

The Model7-dimensional Vector used to describe any DC type

Characteristic Category Possible values for this category for a DC type

Collaborator couplingReceiver countRecipient designationMarshallingExecution transferResponse handlingRecovery handling

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

53

The Model7-dimensional Vector used to describe any DC type

Characteristic Category Possible values for this category for a DC type

Collaborator couplingReceiver countRecipient designationMarshallingExecution transferResponse handlingRecovery handling

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

54

The ModelCharacteristicCategory

Possible values for each category

Collaboratorcoupling

Direct Indirect

Receiver count Exactly 1 1-to-many

Recipientdesignation

Exposed location 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 Distributed transaction support

55

Collaboration Styles in J2EE Applications

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


57

XML/HTTP with DOM and SAX DC Characteristics

Selecting the Appropriate J2EE Middleware

CharacteristicCategory



Direct

Receiver count Exactly 1Recipientdesignation

Recipient

Marshalling Application parses structured bufferExecution transfer Data transfer onlyResponse handling Immediate (blocking) responseRecovery 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

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


59

JMS point-to-point DC Characteristics


Category Characteristics


Indirect

Receiver count One-to-manyRecipientdesignation

Controlled location (queue)

Marshalling Unformatted buffer – application does parsing Formatted structure – application is assisted in parsing Serialized object - application is assisted in parsing

Execution transfer Data transfer onlyResponse 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• A data transport mechanism

60

JMS topics DC Characteristics


Category Characteristics


Indirect

Receiver count One-to-manyRecipientdesignation

Controlled location (topic)

Marshalling Unformatted buffer – application does parsing Formatted structure – application is assisted in parsing Serialized object - application is assisted in parsing

Execution transfer Data transfer onlyResponse 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

• A data transport mechanism

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


62

CORBA Orb DC Characteristics





Direct


Recipient

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)


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

• OO: encapsulation, reference polymorphism, I/F inheritance

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


64





Direct


Recipient


Execution transfer Execution control transfer Transfer of executable code

Response handling Immediate (blocking) responseRecovery handling System Exception handling

User Exception handling Distributed transaction support

Java RMI DC Characteristics

• 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


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





Direct

Receiver count 1-to-many (possibly chained receivers)Recipientdesignation

Recipient

Marshalling Not typesafe Middleware marshals primitive data Middleware marshals compound primitive data Middleware marshals structured data

Execution transfer Execution control transferResponse handling Immediate (blocking) responseRecovery handling Error status returns

Apache Tomcat RPC Router OrbUsing SOAP transport protocol

DC Characteristics

• Software freely available, requires a servlet engine

• “Virtual distributed threads”

• Supports typed interfaces, but not type-safe

67

Selecting the Appropriate J2EE MiddlewareCORBA Orb

Using SOAP transport protocol(rather than IIOP)DC Characteristics




Direct


Recipient


Execution transfer Execution control transfer Transfer of executable code (with difficulty)


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

68

Entity and

Session EJBs

EnterpriseInformation

Tier

External Clients

Business Tier

Serv-let, JSPTM,

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


69

Selecting the Best Collaboration Styles for

J2EE Applications

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

The Scalability Model

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


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)


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 shouldn’t be aware of receiver’s processing


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


76

• Rich API Features - reiterated– Reduced application code

– Extensibility

– Supportability

– Reusability

– Interchangeability

• Encouraged by strong typing and OO


77

• Tensions and Forces


Transport Protocol Compatibility

RichAPIFeatures

Low

High

High

Java RMICORBA IDL

JMS

XML/HTTP

Object Collaboration

Data Transfer

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


79

Conclusions

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

Selecting the BestDistributed Collaboration Styles

for aJ2EE Application

Grant Holland

Senior Java Architect

Sun Microsystems, Inc.

[email protected]

March 28, 2001

Documents

1 Selecting the Best Distributed Collaboration Styles for a J2EE TM Application Grant Holland Senior Java Architect Sun Java Center OReilly Conference