Web Servicses

8/8/2019 Web Servicses

1/51

WEB SERVICESWEB SERVICESRavikumar MaddiRavikumar Maddi


2/51

web services stylesweb services styles

Service StylesService Styles -- RPC, Document, Wrapped, and MessageRPC, Document, Wrapped, and Message

There are four "styles" of service in Axis. RPC services use the SOAP RPC conventions, and also theThere are four "styles" of service in Axis. RPC services use the SOAP RPC conventions, and also theSOAP "section 5" encoding. Document services do not use any encoding (so in particular, you won't seeSOAP "section 5" encoding. Document services do not use any encoding (so in particular, you won't see

multiref object serialization or SOAPmultiref object serialization or SOAP--style arrays on the wire) but DO still do XMLJava databinding.

Wrapped services are just like document services, except that rather than binding the entire SOAP bodyWrapped services are just like document services, except that rather than binding the entire SOAP body

into one big structure, they "unwrap" it into individual parameters. Message services receive and returninto one big structure, they "unwrap" it into individual parameters. Message services receive and return

arbitrary XML in the SOAP Envelope without any type mapping / data binding. If you want to work with thearbitrary XML in the SOAP Envelope without any type mapping / data binding. If you want to work with the

raw XML of the incoming and outgoing SOAP Envelopes, write a message service.raw XML of the incoming and outgoing SOAP Envelopes, write a message service.

Before I go any further, let me clear up some confusion that many of us have stumbled over. TheBefore I go any further, let me clear up some confusion that many of us have stumbled over. The

terminology here is very unfortunate: RPC versus document.terminology here is very unfortunate: RPC versus document. These terms imply that the RPC style shouldThese terms imply that the RPC style shouldbe used for RPC programming models and that the document style should be used for document orbe used for RPC programming models and that the document style should be used for document or

messaging programming models.messaging programming models. That is not the case at all. The style has nothing to do with aThat is not the case at all. The style has nothing to do with a

programming model. It merely dictates how to translate a WSDL binding to a SOAP message. Nothingprogramming model. It merely dictates how to translate a WSDL binding to a SOAP message. Nothing

more. You can use either style with any programming model.more. You can use either style with any programming model.


3/51

Choosing a Web Services StyleChoosing a Web Services Style

Genero Web Services Extension 2.0 allows you to create Web Services operations in theGenero Web Services Extension 2.0 allows you to create Web Services operations in thefollowing styles:following styles:RPC Style Service (RPC/Literal)RPC Style Service (RPC/Literal) is generally used to execute a function, such as a service thatis generally used to execute a function, such as a service thatreturns a stock option.returns a stock option.Document Style ServiceDocument Style Service ((Doc/LiteralDoc/Literal) is generally used for more sophisticated operations that) is generally used for more sophisticated operations thatexchange complex data structures, such as a service that sends an invoice to an application, orexchange complex data structures, such as a service that sends an invoice to an application, or

exchanges a Word document; this is the MS.Net default.exchanges a Word document; this is the MS.Net default.Both RPC/Literal and Doc/Literal Styles are WSBoth RPC/Literal and Doc/Literal Styles are WS--I compliant ( Web Services InteroperabilityI compliant ( Web Services Interoperabilityorganization).organization).RPC Style Service (RPC/Encoded)RPC Style Service (RPC/Encoded) is provided only forbackwards compatibility with olderis provided only forbackwards compatibility with olderversions ofweb services already published. Warning: This style is deprecated by the WSversions ofweb services already published. Warning: This style is deprecated by the WS--IIorganization, and is not recommended, as most Web Service implementations won't support it inorganization, and is not recommended, as most Web Service implementations won't support it inthe future. Seethe future. Seemigrationnotesmigrationnotes if you want your service to be WSif you want your service to be WS--I compliant.I compliant.The style of service to be created is specified in theGenero application for the Web Service, usingThe style of service to be created is specified in theGenero application for the Web Service, usingthe following methods of thethe following methods of theWebOperationWebOperation class from from theclass from from theWeb Services Extension COMWeb Services Extension COM

LibraryLibrary ((comcom). The parameters are the same forboth methods:). The parameters are the same forboth methods:thename of the 4GL function that is executed to process the Web Service operationthename of the 4GL function that is executed to process the Web Service operationthename you wish to assign to the Web Service operationthename you wish to assign to the Web Service operationthe input record defining the input parameters of the operation (or NULL if there is none)the input record defining the input parameters of the operation (or NULL if there is none)the output record defining the output parameters of the operation (or NULL if there is none)the output record defining the output parameters of the operation (or NULL if there is none)


4/51

Service StylesService Styles -- RPC, Document, Wrapped, and MessageRPC, Document, Wrapped, and Message

There are four "styles" of service in Axis.There are four "styles" of service in Axis. RPCRPC services use theservices use theSOAP RPC conventions, and also the SOAP "section 5" encoding.SOAP RPC conventions, and also the SOAP "section 5" encoding.DocumentDocument services do not use any encoding (so in particular, youservices do not use any encoding (so in particular, youwon't see multiref object serialization or SOAPwon't see multiref object serialization or SOAP--style arrays on thestyle arrays on the

wire) but DO still do XMLJava databinding. WrappedWrapped servicesservicesarejust like document services,except that rather thanbinding thearejust like document services,except that rather thanbinding theentire SOAP body into onebig structure, they "unwrap" it intoentire SOAP body into onebig structure, they "unwrap" it intoindividual parameters.individual parameters. MessageMessage services receive and returnservices receive and returnarbitrary XML in the SOAP Envelopewithout any type mapping /arbitrary XML in the SOAP Envelopewithout any type mapping /data binding. If you want to work with the raw XML of the incomingdata binding. If you want to work with the raw XML of the incomingand outgoing SOAP Envelopes,write a message service.and outgoing SOAP Envelopes,write a message service.


5/51

RPC StyleRPC Style

RPC services are the default in Axis. They arewhat you get whenRPC services are the default in Axis. They arewhat you get whenyou deploy services with oryou deploy services with or. RPC services follow the SOAP RPC and. RPC services follow the SOAP RPC andencoding rules,which means that the XML for an RPC servicewillencoding rules,which means that the XML for an RPC servicewilllook like the "echoString" example abovelook like the "echoString" example above -- each RPC invocation iseach RPC invocation is

modeled as an outerelement which matches the operationname,modeled as an outerelement which matches the operationname,containing innerelements each ofwhich maps to a parameter of thecontaining innerelements each ofwhich maps to a parameter of theoperation. Axis will deserialize XML into Java objects which canbeoperation. Axis will deserialize XML into Java objects which canbefed to your service, and will serialize the returned Java object(s)fed to your service, and will serialize the returned Java object(s)from your serviceback into XML. Since RPC services default to thefrom your serviceback into XML. Since RPC services default to thesoap section 5 encoding rules, objects will beencoded via "multisoap section 5 encoding rules, objects will beencoded via "multi--ref"ref"serialization,which allows object graphs to beencoded. (See theserialization,which allows object graphs to beencoded. (See the

SOAP spec for more on multiSOAP spec for more on multi--ref serialization.)ref serialization.)


6/51

Document / Wrapped servicesDocument / Wrapped services

Document services and wrapped services are similar in that neither uses the SOAPDocument services and wrapped services are similar in that neither uses the SOAP

encoding for data; it's just plain old XML schema. In both cases, however, Axis still "binds"encoding for data; it's just plain old XML schema. In both cases, however, Axis still "binds"Java representations to the XML (see theJava representations to the XML (see the databindingdatabinding section for more), so you end upsection for more), so you end up

dealing with Java objects, not directly with XML constructs.dealing with Java objects, not directly with XML constructs.

A good place to start in describing the difference between document and wrapped servicesA good place to start in describing the difference between document and wrapped services

is with a sample SOAP message containing a purchase order:is with a sample SOAP message containing a purchase order:

SK001SK001

11Sushi KnifeSushi Knife

The relevant schema for the PurchaseOrder looks like this:The relevant schema for the PurchaseOrder looks like this:


7/51

Document vs. WrapperDocument vs. Wrapper

For a document style service, this would map to a method like this:For a document style service, this would map to a method like this:

public void method(PurchaseOrder po)public void method(PurchaseOrder po)

In other words, the ENTIRE element would be handed to your method as a single bean with three fields inside iIn other words, the ENTIRE element would be handed to your method as a single bean with three fields inside it.t. OnOnthe other hand, for a wrapped style service, it would map to a method like this:the other hand, for a wrapped style service, it would map to a method like this:

public void purchaseOrder(String item, int quantity, String description)public void purchaseOrder(String item, int quantity, String description)

Note that in the "wrapped" case, the element is a "wrapper" (hence the name) which only serves to indicate thNote that in the "wrapped" case, the element is a "wrapper" (hence the name) which only serves to indicate thee

correct operation. The arguments to our method are what we find when we "unwrap" the outer element and take each of thecorrect operation. The arguments to our method are what we find when we "unwrap" the outer element and take each of the

inner ones as a parameter.inner ones as a parameter.

The document or wrapped style is indicated in WSDD as follows:The document or wrapped style is indicated in WSDD as follows:

for document style for document style

for wrapped style for wrapped style

In most cases you won't need to worry about document or wrapped services if you are starting from a WSDL documentIn most cases you won't need to worry about document or wrapped services if you are starting from a WSDL document


8/51

Web services JMS JCA Comments

Interface coupling(abstract servicedefinition)

YESDynamic interface discovery and requestconstruction is possible

NOPayloadagnostic

YES YES meanstight coupling

Technical coupling(protocol stack)

NOWith WSIF, client is not bound to a clientlibrary for a particular protocol implementation

YES YES YES meanstight coupling

Portability YESMulti-language

NOJava technologyonly

NOJavatechnologyonly

Reliability HTTP-R binding for SOAP YES Specific

TransactionalSupport

FutureWS-Coordination & WS-TransactionCompensation and XA models

Limited in scopeOnly to thequeueentrypoint

YESXA model

Security Limited to SOAPSOAP-SEC, superseded by WS-Security

Not part of thestandard, hencevendor-specific

Integrationbetween EISand J2EE

Synchronous mode YESMajor use

Do it yourself YES

Asynchronous mode YESDocument oriented interface

YES Futur e

Event-driven, pushmode

YESDocument oriented interface or flow support

(WSFL, BPEL4WS)

YES Futur e


9/51

IntroductionIntroduction

Organizations evolve rapidly, and they seek to meet changing business requirements whileOrganizations evolve rapidly, and they seek to meet changing business requirements while

managing costs. This means that enterprises desire to structure their own applications in amanaging costs. This means that enterprises desire to structure their own applications in away that allows easy reorganization of information systems. Major organizational changesway that allows easy reorganization of information systems. Major organizational changes

such as mergers or the creation of subsidiaries might also introduce new variables into thesuch as mergers or the creation of subsidiaries might also introduce new variables into the

information system.information system.

Enterprises might also need to buy applications on the market or to subcontract part ofEnterprises might also need to buy applications on the market or to subcontract part of

their business needs, such as ledger or backtheir business needs, such as ledger or back--office management. There is no guaranteeoffice management. There is no guarantee

that such services are available on the existing technical framework.that such services are available on the existing technical framework.

As the complexity of information system increases, development must be simplified. ThisAs the complexity of information system increases, development must be simplified. Thisbrought about interest inbrought about interest in Enterprise Application IntegrationEnterprise Application Integration (EAI). Still, enterprises must(EAI). Still, enterprises must

complement EAI with business services and a flexible way to access the resulting,complement EAI with business services and a flexible way to access the resulting,

integrated applications.integrated applications.

InterfaceInterface--based architectures currently address this increasing need for flexible access tobased architectures currently address this increasing need for flexible access to

business services and client independence. Interfacebusiness services and client independence. Interface--based architectures include suchbased architectures include such

technologies astechnologies as web servicesweb services,, J2C Connector ArchitectureJ2C Connector Architecture (JCA; see(JCA; see ResourcesResources for morefor more

information) andinformation) and Java Message ServiceJava Message Service (JMS). They also include all of the variations of the(JMS). They also include all of the variations of the

command pattern, which isolates client code from the implementation of the businesscommand pattern, which isolates client code from the implementation of the businessservice. You can call such invocation frameworks from EAI middleware, and vice versa.service. You can call such invocation frameworks from EAI middleware, and vice versa.

In this article we first discuss the main characteristics of each interface technology, andIn this article we first discuss the main characteristics of each interface technology, and

then the requirements that suggest one or another. After reading this article, you willthen the requirements that suggest one or another. After reading this article, you will

understand how to position the various technologies and how to choose among them for aunderstand how to position the various technologies and how to choose among them for a

particular implementation.particular implementation.


10/51

Web services, JCA, and JMS characteristicsWeb services, JCA, and JMS characteristics

This section outlines the interface technologies of interest and details some of theirThis section outlines the interface technologies of interest and details some of their

characteristics.characteristics.Web servicesWeb services

Web services are an implementation of Services Oriented ArchitecturesWeb services are an implementation of Services Oriented Architectures

(SOA). A SOA has three parties: a provider, a broker, and a requester,(SOA). A SOA has three parties: a provider, a broker, and a requester,

which are loosely coupled. The provider offers a business service thatwhich are loosely coupled. The provider offers a business service that

represents a particular implementation, which is not directly visible to therepresents a particular implementation, which is not directly visible to the

requester. The requester learns from the broker the information structurerequester. The requester learns from the broker the information structure

that it has to send and receive from the provider and what protocol to usethat it has to send and receive from the provider and what protocol to use

to access that service. The requester has no knowledge of the way theto access that service. The requester has no knowledge of the way the

provider implements the business service.provider implements the business service.

Web services are defined as required business interfaces between aWeb services are defined as required business interfaces between a

requester and a provider, and not as a common pipe for all businessrequester and a provider, and not as a common pipe for all business

requests. There are several variables that can characterize web services,requests. There are several variables that can characterize web services,

including that:including that: They can be tightly coupled, and their deployment can be based on the useThey can be tightly coupled, and their deployment can be based on the use

of invocation frameworks.of invocation frameworks.

They can perform either in a synchronous request/reply mode or in anThey can perform either in a synchronous request/reply mode or in an

asynchronous mode.asynchronous mode.

They can be exposed by J2EE or nonThey can be exposed by J2EE or non--J2EE providers.J2EE providers.

They might or might not offer support for transactions and security.They might or might not offer support for transactions and security.


11/51

JCAJCA

Java Connector Architecture mainly addresses the need to access theJava Connector Architecture mainly addresses the need to access the

business logic ofbusiness logic ofEnterprise Information SystemsEnterprise Information Systems (EIS) in a tightly(EIS) in a tightly--coupledcoupledway. Connector architecture provides support for resource adaptation, whichway. Connector architecture provides support for resource adaptation, which

maps the J2EE security, transaction, and communication pooling to themaps the J2EE security, transaction, and communication pooling to the

corresponding EIS technology.corresponding EIS technology.

Initially, connectors were intended to access legacy transaction servers onInitially, connectors were intended to access legacy transaction servers on

mainframes in a synchronous request/reply mode, and this is how the majoritymainframes in a synchronous request/reply mode, and this is how the majority

of connectors work today. The standard is currently evolving toward moreof connectors work today. The standard is currently evolving toward more

asynchronous and twoasynchronous and two--way connectivity.way connectivity.

Some userSome user--defined variants of the connector are more sophisticated and workdefined variants of the connector are more sophisticated and work

on a logical connection mode. As such, they can behave as invocationon a logical connection mode. As such, they can behave as invocation

frameworks, selecting the appropriate physical EIS target and businessframeworks, selecting the appropriate physical EIS target and business

operations in a manner similar to web services.operations in a manner similar to web services.


12/51

JMSJMS

JMS is an asynchronous messageJMS is an asynchronous message--based interface. You can also use JMS tobased interface. You can also use JMS to

access business logic distributed among heterogeneous systems. Having aaccess business logic distributed among heterogeneous systems. Having amessagemessage--based interface enables the following functions:based interface enables the following functions:

Point to point and publish/subscribe mechanisms. MessagePoint to point and publish/subscribe mechanisms. Message--based frameworksbased frameworks

can push information to other applications without their requesting it explicitly.can push information to other applications without their requesting it explicitly.

The same information can be delivered to many subscribers in parallel.The same information can be delivered to many subscribers in parallel.

Rhythm independence. JMS frameworks function in asynchronous mode butRhythm independence. JMS frameworks function in asynchronous mode but

also offer the capability of simulating a synchronous request/response mode.also offer the capability of simulating a synchronous request/response mode.This allows source and target systems to work simultaneously without havingThis allows source and target systems to work simultaneously without having

to wait for each other.to wait for each other.

Guaranteed information delivery. JMS frameworks can manage the messagesGuaranteed information delivery. JMS frameworks can manage the messages

in transactional mode and ensure message delivery (but without any guaranteein transactional mode and ensure message delivery (but without any guarantee

of timeliness of delivery).of timeliness of delivery).

Interoperability between heterogeneous frameworks. The source and targetInteroperability between heterogeneous frameworks. The source and target

applications can operate in heterogeneous environments without having toapplications can operate in heterogeneous environments without having tohandle problems of communication and execution related to their respectivehandle problems of communication and execution related to their respective

frameworks.frameworks.

Making exchanges more fluid. The switch to message mode allows finerMaking exchanges more fluid. The switch to message mode allows finer--

grained information exchange.grained information exchange.


13/51

Choosing interface technologiesChoosing interface technologiesThe way you have already implemented business logic in your system willThe way you have already implemented business logic in your system will

naturally lead you towards one of these technologies. As a first step towardsnaturally lead you towards one of these technologies. As a first step towardsmaking a choice, analyze your existing infrastructure. Is there an existingmaking a choice, analyze your existing infrastructure. Is there an existing

messaging system, or a legacy system such as CICS or IMS?messaging system, or a legacy system such as CICS or IMS?

In many cases the most natural way to access mainframe EIS such as CICS orIn many cases the most natural way to access mainframe EIS such as CICS or

IMS is through the Java Connector Architecture. If on the other hand, you needIMS is through the Java Connector Architecture. If on the other hand, you need

to access .NET applications, you will probably tend towards a web servicesto access .NET applications, you will probably tend towards a web services

interface. In yet other cases you might use a JMS interface, which allows theinterface. In yet other cases you might use a JMS interface, which allows the

exchange of messages with little constraint on the implementation language.exchange of messages with little constraint on the implementation language.Use the following summary of decision points:Use the following summary of decision points:

You have existing Java applications or plan a new one: use JMS or JCA.You have existing Java applications or plan a new one: use JMS or JCA.

You need to interact with partners: use web services for transport and connection.You need to interact with partners: use web services for transport and connection.

You need to cross the barrier between languages: use JMS or web services.You need to cross the barrier between languages: use JMS or web services.

Another factor in decisionAnother factor in decision--making is the scope of the network: whethermaking is the scope of the network: whether

Internet, intranet, or extranet. This scope determines your flexibility inInternet, intranet, or extranet. This scope determines your flexibility inchoosing the transport protocol. Deployment on the Internet probably demandschoosing the transport protocol. Deployment on the Internet probably demands

looselyloosely--coupled web services over HTTP. This would work with existing firewallcoupled web services over HTTP. This would work with existing firewall

andand demilitarized zonedemilitarized zone (DMZ) infrastructure, and you can minimize the cost.(DMZ) infrastructure, and you can minimize the cost.

JMS and JCA make more sense as Intranet or Extranet protocols. JMS isJMS and JCA make more sense as Intranet or Extranet protocols. JMS is

suitable for asynchronous mode or simulated synchronous mode, and JCA issuitable for asynchronous mode or simulated synchronous mode, and JCA is

suitable for tighter coupling.suitable for tighter coupling.


14/51

What the options have in commonWhat the options have in common

Web services are not synonymous with services offered over SOAP. You canWeb services are not synonymous with services offered over SOAP. You can

consider any piece of code with aconsider any piece of code with a Web services Description LanguageWeb services Description Language (WSDL)(WSDL)description of its functionality and access protocols a web service. You candescription of its functionality and access protocols a web service. You can

make any such service available over multiple transports and protocols.make any such service available over multiple transports and protocols.

You can therefore adopt a WSDLYou can therefore adopt a WSDL--centric approach, described and implementedcentric approach, described and implemented

by theby the Web services Invocation FrameworkWeb services Invocation Framework(WSIF). This ties together your(WSIF). This ties together your

choices for integration regardless of the scope of the network: intranet,choices for integration regardless of the scope of the network: intranet,

extranet, or Internet.extranet, or Internet.

You probably seek to leave the broadest options for future expansion plans,You probably seek to leave the broadest options for future expansion plans,

including extension of existing enterprise systems or making connections toincluding extension of existing enterprise systems or making connections to

business partners. To facilitate this, you can describe the same businessbusiness partners. To facilitate this, you can describe the same business

component in a single WSDL document, which you can:component in a single WSDL document, which you can:

Make available on different protocols, such as SOAP and RMIMake available on different protocols, such as SOAP and RMI--IIOP, through the notionIIOP, through the notion

ofofinbound bindingsinbound bindings. RMI is Java remote Message Invocation. IIOP (Internet Inter. RMI is Java remote Message Invocation. IIOP (Internet Inter--ORBORB

protocol) is the CORBA wire protocol.protocol) is the CORBA wire protocol. Implement with different types of components, such as JCA or JMSImplement with different types of components, such as JCA or JMS--basedbased

components, through the notion ofcomponents, through the notion ofoutbound bindingsoutbound bindings..


15/51

Following this approach, JMS and JCA are just a couple of the protocols that a serverFollowing this approach, JMS and JCA are just a couple of the protocols that a server

provider might use to implement a business component. Different network and interfaceprovider might use to implement a business component. Different network and interfacetechnologies then affect only nontechnologies then affect only non--functional matters such as security, performance,functional matters such as security, performance,

response time, and availability. When the same component is available on an intranetresponse time, and availability. When the same component is available on an intranet

and the Internet, the two networks will differ in the security required, the performanceand the Internet, the two networks will differ in the security required, the performance

expected, and the availability demanded.expected, and the availability demanded.

The WSDLThe WSDL--centric approach for web services gives you the ability to decouple thecentric approach for web services gives you the ability to decouple the

abstract interface from the exact protocol stack. You can implement this approach inabstract interface from the exact protocol stack. You can implement this approach in

two ways, both of which leverage WSIF:two ways, both of which leverage WSIF:

1.1. With the IBM Web services Gateway (WSGW), existing WSDL descriptions areWith the IBM Web services Gateway (WSGW), existing WSDL descriptions are

deployed and made available through SOAP channels. The inbound binding isdeployed and made available through SOAP channels. The inbound binding is

SOAP, and the outbound binding is the existing WSDL implementationSOAP, and the outbound binding is the existing WSDL implementation

description.description.

2.2. With the IBM WebSphere Studio Application Developer Integration EditionWith the IBM WebSphere Studio Application Developer Integration Edition

(WSAD(WSAD--IE), existing WSDL descriptions are consumed and made availableIE), existing WSDL descriptions are consumed and made available

through SOAP or RMIthrough SOAP or RMI--IIOP proxiesIIOP proxies..


16/51

Interaction patternsInteraction patterns

When architecting applications, you define patterns of interaction. These patterns generallyWhen architecting applications, you define patterns of interaction. These patterns generally

reveal your preference for technical integration.reveal your preference for technical integration.EventEvent--driven, push modeldriven, push model

Listeners that wait for events provide the standard event push model, which is particularlyListeners that wait for events provide the standard event push model, which is particularly

important to EAI. Business process automation often requires the capture of applicationimportant to EAI. Business process automation often requires the capture of application

events for propagation to other integrated applications.events for propagation to other integrated applications.

Standard listeners for business services often use JMS or HTTP servers. Message DrivenStandard listeners for business services often use JMS or HTTP servers. Message Driven

Beans in EJB use JMS, while web services use HTTP.Beans in EJB use JMS, while web services use HTTP.

In this push model, the pushed events trigger processes. The web services community hasIn this push model, the pushed events trigger processes. The web services community hasdone a lot of work to formalize the choreography of this process interaction. In particular,done a lot of work to formalize the choreography of this process interaction. In particular,

thethe web services Flow Languageweb services Flow Language (WSFL) and(WSFL) and Business Process Execution Language forBusiness Process Execution Language for

Web servicesWeb services (BPEL4WS) standards address such event sequencing.(BPEL4WS) standards address such event sequencing.

In WSFL the flow engine can execute a new flow instance in response to an incoming messageIn WSFL the flow engine can execute a new flow instance in response to an incoming message

(marked by the(marked by the spawnspawn lifecycle operation). Its support for onelifecycle operation). Its support for one--way interaction provides support forway interaction provides support fornotification.notification.

In BPEL4WS,In BPEL4WS, receivereceive ororpickpickactivities can implicitly start business processes in response toactivities can implicitly start business processes in response to

incoming messages;incoming messages;pickpickactivities can select the process to run based on one of a set of events.activities can select the process to run based on one of a set of events.


17/51

Synchronous request/reply modeSynchronous request/reply mode

In the enterprise, performance requirements may suggest a JCA implementation, especially whenIn the enterprise, performance requirements may suggest a JCA implementation, especially whenmost of the business logic is currently in some existing EIS. However connectors are not availablemost of the business logic is currently in some existing EIS. However connectors are not available

to access all systems, and in some cases adding message layers with JMS is the only solution.to access all systems, and in some cases adding message layers with JMS is the only solution.

Messaging is not the primary choice for request/responseMessaging is not the primary choice for request/response--type interactions. Implementingtype interactions. Implementing

request/response with messaging middleware prevents the transactional coordination betweenrequest/response with messaging middleware prevents the transactional coordination between

caller and called because of the isolation implied by messaging. Also, response timeouts have to becaller and called because of the isolation implied by messaging. Also, response timeouts have to be

managed by the caller's programming logic rather than a provided connector implementation.managed by the caller's programming logic rather than a provided connector implementation.

Asynchronous modelAsynchronous model

All three interface technologiesAll three interface technologies ---- web services, JMS, and even JCAweb services, JMS, and even JCA ---- can work in asynchronouscan work in asynchronousmode. The requests or events would be sent to the target without expecting an answer other than:mode. The requests or events would be sent to the target without expecting an answer other than:

"The message was delivered correctly." It is a fire"The message was delivered correctly." It is a fire--andand--forget style of interaction.forget style of interaction.

Supporting this model is not a major issue in an architecture, and the techniques you use can beSupporting this model is not a major issue in an architecture, and the techniques you use can be

similar to those in other models. Usually you will pair an asynchronous model with event pushsimilar to those in other models. Usually you will pair an asynchronous model with event push

support or a polling mechanism, and it is probably these details that will suggest a particularsupport or a polling mechanism, and it is probably these details that will suggest a particular

technology for implementation.technology for implementation.

In the case of web services, asynchronous interactions are supported, although tools are notIn the case of web services, asynchronous interactions are supported, although tools are not

typically welltypically well--suited to this form. SOAPsuited to this form. SOAP--based web services support not only a synchronous RPCbased web services support not only a synchronous RPC

interaction mode, but also an asynchronous message interaction mode. The basis of this is theinteraction mode, but also an asynchronous message interaction mode. The basis of this is thedocumentdocument--oriented model, in which both requester and supplier must deal with SOAP envelopeoriented model, in which both requester and supplier must deal with SOAP envelope

formatting and parsing.formatting and parsing.

The documentThe document--oriented model is a way of implementing true oneoriented model is a way of implementing true one--way communication.way communication.


18/51

Requirements and implications of technology choicesRequirements and implications of technology choices

This next section addresses nonThis next section addresses non--functional requirements that serve as decision factors in choosing an accessfunctional requirements that serve as decision factors in choosing an access

technology for business logic.technology for business logic.Loose or tight couplingLoose or tight coupling

Tight coupling means that there is a nailedTight coupling means that there is a nailed--down, predetermined clientdown, predetermined client--server orserver or

consumerconsumer--publisher relationship that is not so easy to change. In such a case youpublisher relationship that is not so easy to change. In such a case you

typically have for a given client only one specific server with technical interaction thattypically have for a given client only one specific server with technical interaction that

is faultis fault--sensitive, meaning that the client has to handle protocolsensitive, meaning that the client has to handle protocol--related errors. Yourelated errors. You

can see this tight coupling at the interface definition level, or at the protocol stackcan see this tight coupling at the interface definition level, or at the protocol stack

level. You might be tied to a specific, abstract definition of the service or to a specificlevel. You might be tied to a specific, abstract definition of the service or to a specific

protocol stack to reach the service.protocol stack to reach the service. LooselyLoosely--coupled systems are often designed to work on a problem partitioned aroundcoupled systems are often designed to work on a problem partitioned around

data flow boundaries, in which workers solve only one part of a larger problem, thedata flow boundaries, in which workers solve only one part of a larger problem, the

context of which is not necessarily known. Often such systems are inherentlycontext of which is not necessarily known. Often such systems are inherently

extensible by means of adding more workers.extensible by means of adding more workers.

You might be loosely coupled in the following ways:You might be loosely coupled in the following ways:

By providing a public contract that describes the relationship between the consumer/client andBy providing a public contract that describes the relationship between the consumer/client and

the producer/server, and you can safely build and integrate your application without having tothe producer/server, and you can safely build and integrate your application without having to

let other people know about the technical details of your application (and how it changes overlet other people know about the technical details of your application (and how it changes over

time). By the same token, you can use other developers' public contracts to consume theirtime). By the same token, you can use other developers' public contracts to consume their

applications without needing to know the details.applications without needing to know the details.

By providing a protocol stack that will deal with connectionless interactions againstBy providing a protocol stack that will deal with connectionless interactions against

anonymous servers, and you can safely interact with components through faultanonymous servers, and you can safely interact with components through fault--resilientresilient

mechanisms.mechanisms.

By providing payloadBy providing payload--agnostic communication channels, in particular through brokeragnostic communication channels, in particular through broker--basedbased

messaging systems.messaging systems.

Now we map the three technologies in question to tight or loose coupling.Now we map the three technologies in question to tight or loose coupling.


19/51

JCA is a technique for tight coupling.JCA is a technique for tight coupling.

JCA is a J2EE standard that ties the request and the connected Enterprise InformationJCA is a J2EE standard that ties the request and the connected Enterprise Information

Systems using a container. The container is a coupler providing managed mode supportSystems using a container. The container is a coupler providing managed mode supportfor security, transaction scope, connection management propagation, and interaction withfor security, transaction scope, connection management propagation, and interaction with

the target system.the target system.

The JCA coupling interface is strictly defined through Common Client Interface.The JCA coupling interface is strictly defined through Common Client Interface.

System contracts and containerSystem contracts and container--component contracts are hidden for the applicationcomponent contracts are hidden for the application

component, but they do strongly link caller and called.component, but they do strongly link caller and called.

JCA does not yet address business issues such as billing and auditing. ImplementingJCA does not yet address business issues such as billing and auditing. Implementing

those requirements remains a problem of application business architecture.those requirements remains a problem of application business architecture.


20/51

JMS is a technique for loose couplingJMS is a technique for loose coupling

JMS is a technique for loose coupling. As an example, it does not provideJMS is a technique for loose coupling. As an example, it does not provide

security or transactional binding with the target systems, but only with thesecurity or transactional binding with the target systems, but only with themessage middleware. Messaging in general achieves loose coupling because:message middleware. Messaging in general achieves loose coupling because:

Message producers and consumers interact through the messaging transport (suchMessage producers and consumers interact through the messaging transport (such

as a message broker) in a pointas a message broker) in a point--toto--point or publish/subscribe model.point or publish/subscribe model.

A technical header is usually provided independently of the business payload.A technical header is usually provided independently of the business payload.

JMS is wellJMS is well--suited for:suited for:

Integrating systems/components that participate in business events.Integrating systems/components that participate in business events.

Integrating slow responders.Integrating slow responders.

Integrating existing systems.Integrating existing systems.

Web services target business services rather than technical connectivity. TheyWeb services target business services rather than technical connectivity. They

are primarily implemented using loose technical coupling but tight coupling atare primarily implemented using loose technical coupling but tight coupling at

the interfacethe interface--definition level.definition level.


21/51

Web services target business services rather than technical connectivity. They are primarily implementedWeb services target business services rather than technical connectivity. They are primarily implemented

using loose technical coupling but tight coupling at the interfaceusing loose technical coupling but tight coupling at the interface--definition level.definition level.With web services the coupling is based on both an interface definition and a protocol binding.With web services the coupling is based on both an interface definition and a protocol binding.

The contract is published in WSDL, which defines the interface, which defines the available operations.The contract is published in WSDL, which defines the interface, which defines the available operations.

The protocol used to access a web service may vary. This protocol is known as the inbound binding and defines how toThe protocol used to access a web service may vary. This protocol is known as the inbound binding and defines how toget to the implementation artifact.get to the implementation artifact.

The way to access the implementation may vary as well. This protocol is known as the outbound binding, and defines theThe way to access the implementation may vary as well. This protocol is known as the outbound binding, and defines the

artifact implementing the public contract. Examples include JavaBeans, EJB, and JCA.artifact implementing the public contract. Examples include JavaBeans, EJB, and JCA.

The style of coupling in web services offers flexibility, with two kinds of binding: static and dynamic.The style of coupling in web services offers flexibility, with two kinds of binding: static and dynamic.

Static binding implies tight coupling: the requester uses the service implementation obtained at design time; no privateStatic binding implies tight coupling: the requester uses the service implementation obtained at design time; no private

or shared registry is used.or shared registry is used.

Dynamic binding implies loose coupling: the requester discovers at runtime the implementation to be used for theDynamic binding implies loose coupling: the requester discovers at runtime the implementation to be used for theservice called; it might even determine at runtime the interface that should be called.service called; it might even determine at runtime the interface that should be called.

In reality, most of today's web services use SOAP as the inbound protocol. UntilIn reality, most of today's web services use SOAP as the inbound protocol. Until class of serviceclass of service is supported,is supported,SOAP will rather be a loose coupling protocol. Class of service will address security, reliability, andSOAP will rather be a loose coupling protocol. Class of service will address security, reliability, and

availability.availability.

SOAP is still the default protocol because of its ubiquity, firewallSOAP is still the default protocol because of its ubiquity, firewall--friendliness, and other advantages. Also,friendliness, and other advantages. Also,

SOAP is where web services security specifications are currently being developed; so in practice,SOAP is where web services security specifications are currently being developed; so in practice,

defining a standard security approach implies using SOAP.defining a standard security approach implies using SOAP.Some other auxiliary business functions, such as billing and auditing, are now available for web services.Some other auxiliary business functions, such as billing and auditing, are now available for web services.


22/51

Portability and interoperabilityPortability and interoperability

Web services impose no programming language or operating systemWeb services impose no programming language or operating system

limitations between caller and called. In the near future some SOAPlimitations between caller and called. In the near future some SOAPinteroperability issues are likely to be addressed, such as differencesinteroperability issues are likely to be addressed, such as differences

between the Apache implementation and others. After this is resolved,between the Apache implementation and others. After this is resolved,

all platforms supporting web services will interoperate (including .NETall platforms supporting web services will interoperate (including .NET

and J2EE platforms). But even then, web service client or serverand J2EE platforms). But even then, web service client or server

implementation code will not be portable between vendors.implementation code will not be portable between vendors.

Implementation code written for .NET will, of course, not run underImplementation code written for .NET will, of course, not run underJ2EE.J2EE.

JMS and JCA only address the Java world. With JCA the portability isJMS and JCA only address the Java world. With JCA the portability is

achieved on the Java client code side, and interoperability is limited toachieved on the Java client code side, and interoperability is limited to

a specific target. JMS requires Java environments on both sides toa specific target. JMS requires Java environments on both sides to

interoperate at a technical level, but the message payload is agnostic,interoperate at a technical level, but the message payload is agnostic,

and using JAXM web services, SOAP payloads can be carried on JMS.and using JAXM web services, SOAP payloads can be carried on JMS.


23/51

Transactional supportTransactional support

JCA does not always support endJCA does not always support end--toto--end transactional support to an EIS. Asend transactional support to an EIS. As

mentioned earlier, the connector provider implements a container thatmentioned earlier, the connector provider implements a container that

propagates the transactional context to the target systems. This is donepropagates the transactional context to the target systems. This is done

through the transaction management system contract, in which the containerthrough the transaction management system contract, in which the container

acts as a transaction manager controlling the EIS as a resource manager. Thisacts as a transaction manager controlling the EIS as a resource manager. This

is based on theis based on the XAXA standard (seestandard (see ResourcesResources for more information).for more information).

Web services do not currently support transactions. Standards bodies areWeb services do not currently support transactions. Standards bodies areworking on ways to provide transactional support on a looselyworking on ways to provide transactional support on a loosely--coupled modelcoupled model

with the WSwith the WS--Coordination and WSCoordination and WS--transaction standards. In the future both atransaction standards. In the future both a

looslyloosly--coupled model using compensation and a tightlycoupled model using compensation and a tightly--coupled model usingcoupled model using

an XAan XA--like transactional model will be available.like transactional model will be available.

In the messaging model, once the message has been delivered to the queue,In the messaging model, once the message has been delivered to the queue,

the client has no control on its propagation. So JMS can only supportthe client has no control on its propagation. So JMS can only support

transactions to the queue entry point and not to the target application.transactions to the queue entry point and not to the target application.


24/51

ReliabilityReliabilityCurrently the only assured delivery is through JMS (although there is no guarantee onCurrently the only assured delivery is through JMS (although there is no guarantee onmessage delay). For the future, IBM, Microsoft, BEA, and TIBCO jointly propose standardmessage delay). For the future, IBM, Microsoft, BEA, and TIBCO jointly propose standard

mechanisms for exchanging secure, reliable messages in a web services environment. Youmechanisms for exchanging secure, reliable messages in a web services environment. You

can access these standards on the web Services organization site (seecan access these standards on the web Services organization site (see ResourcesResources). The). The

reliability of the JCA connection will always be connectorreliability of the JCA connection will always be connector--specific, and JCA itself does notspecific, and JCA itself does not

imply reliability.imply reliability.

SecuritySecuritySecurity is the least standardized domain. In JMS the specification explicitly states thatSecurity is the least standardized domain. In JMS the specification explicitly states that

security is left to the JMS provider implementation, which is compatible with the rest ofsecurity is left to the JMS provider implementation, which is compatible with the rest of

J2EE security. Fortunately, IBM also adheres to this standard. With JCA the support of theJ2EE security. Fortunately, IBM also adheres to this standard. With JCA the support of the

security will depend on the capability of the connector container and targeted enterprisesecurity will depend on the capability of the connector container and targeted enterprise

information system implementation.information system implementation.

HTTPS support can provide some web services security at the transport layer. However,HTTPS support can provide some web services security at the transport layer. However,

after the web server deciphers and authenticates the request, it is vulnerable, and onlyafter the web server deciphers and authenticates the request, it is vulnerable, and only

some web services implementations using the SOAP Security Extensions (SOAPsome web services implementations using the SOAP Security Extensions (SOAP--SEC)SEC)

support the currentlysupport the currently--available security (seeavailable security (see ResourcesResources for more information on SOAPfor more information on SOAP--

SEC). Standardization work is being undertaken in the WSSEC). Standardization work is being undertaken in the WS--Security standard that shouldSecurity standard that should

enable a fully interoperable endenable a fully interoperable end--toto--end security model in the future.end security model in the future.


25/51

ConclusionConclusionAs you can see, the choice amongweb services, JMS, and JCA implementations for integration is based on multiple criteria.By mapping to the requirements for particular solutions, and by prioritizing these requirements, architects can choose the rightimplementation for their particular case.The following table summarizes what we have said so far, and lays out decision criteria:

Web services JMS JCA Comments

Interface coupling(abstract servicedefinition)

YESDynamic interface discovery and requestconstruction is possible

NOPayload agnostic

YES YES means tight coupling

Technicalcoupling (protocolstack)

NOWith WSIF, client is not bound to a clientlibrary for a particular protocol

implementation

YES YES YES means tight coupling

Portability YESMulti-language

NOJava technology only

NOJava technology only

Reliability HTTP-R binding for SOAP YES Specific

TransactionalSupport

FutureWS-Coordination& WS-TransactionCompensation and XA models

Limited in scopeOnly to thequeueentrypoint

YESXA model

Security Limited to SOAPSOAP-SEC, superseded by WS-Security

Not part of thestandard, hencevendor-specific

Integrationbetween EISand J2EE

Synchronousmode

YESMajor use

Do it yourself YES

Asynchronousmode

YESDocument oriented interface

YES Futur e

Event-driven,push mode

YESDocument oriented interface or flow support

(WSFL,BPEL4WS)

YES Futur e


26/51


27/51


28/51


29/51


30/51


31/51


32/51


33/51


34/51


35/51


36/51


37/51


38/51


39/51


40/51


41/51


42/51


43/51


44/51


45/51


46/51


47/51


48/51


49/51


50/51


51/51

Documents

Web Servicses