Web Services Integration Patterns, Part 1
by Massimiliano Bigatti
|
Pages: 1, 2
Participants and collaborations
The Service Proxy Object element represents the business service,
which encapsulates the application domain logic. Every
if and for here is business oriented.
The Channel object provides the technical support for
implementing the communication, providing the access to the
specific wire protocol.
The Service Proxy object has a strict coupling with the Channel
object, which conforms to a specific interface. When the
call() method is invoked, the input data is passed to
the channel object, along with information like authentication data
or service URI. The Channel object then invokes the service,
returning the response to the Service Proxy.
Sample code
The following class is an implementation of the Exchange Services that demands the low level communication to a channel object. The channel also implements setter methods for user/password and the URI for the service to call.
public class ExchangeService extends AbstractService {
String country1;
String country2;
float rate;
Channel channel;
public ExchangeService( String user, String password, Channel channel ) {
this.channel = channel;
this.channel.setUser( user );
this.channel.setUser( password );
this.channel.setServiceURI( "http://myrates.com/services/exchange/" );
}
public void call() throws ServiceException {
try {
channel.setParameter("country1", country1);
channel.setParameter("country2", country2);
channel.call();
rate = channel.getResultAsFloat(
"\\SOAP:Envelope\SOAP:Body\getRateResponse\rate"
);
} catch( ChannelException ex ) {
throw new ServiceException( ex );
}
}
public void setCountry1( String country ) {
country1 = country;
}
public void setCountry2( String country ) {
country2 = country;
}
public float getRate() {
return rate;
}
}
The generic interface implements a method that obtains the response
value specifing an XPath expression to the requested node (see
Using
XPath with SOAP).
Service Coordinator
Interaction between the program and other services is mediated by a coordinator
Often business processes require the interaction of several services. Sometimes such coordination is performed by off-the-shelf web services orchestraction products; sometimes it is implemented by the application logic.
The coordinator class implements the second option, that is, it implements the logic required to manage the interaction between the services.
|
Related Reading 
Programming Web Services with SOAP |
The services you need to integrate in the process could raise questions. For instance, they could require a distribuited transaction system or the output from one service is used as input for another service. In such cases implementing the logic in the client code ties the particular process required to perform a business function with the available services to the application. But the problem is that the process could change, maybe because the required services change themselves. As a result, the developer must rewrite the orchestration code inside the application.
A better approach is to have a third element that encloses only the logic needed to coordinate the required service. The logic is thus specific to the service used but responds to the business interface required by the application.
The client class requests the operation to the coordinator, which in turn calls the proxies as requested by the logic contained in the coordinator object.
All the logic related to the coordination of the service for a particular business action is encapsulated in a single class, making the program more clear. The client code is simpler, as it calls only the facade method of the Service Coordinator object, running the whole process.
Sample code
The following example uses two services, coordinating the execution between them. TheCountryLookupService service returns
the country code required by the ExchangeService,
converting a specific currency to the correspondent country code.
The country codes are then used to invoke the Exchange Service; the
rate returned is then used to calculate the exchange rate:
public class CurrencyExchangeCoordinator {
Service lookup;
Service exchange;
public CurrencyExchangeCoordinator() {
lookup = new CountryLookupService();
exchange = new ExchangeService();
}
public float exchange( String currencyFrom, String currencyTo,
float value ) throws ServiceException {
lookup.setCurrency( currencyFrom );
lookup.call();
String country1 = lookup.getCountry();
lookup.setCurrency( currencyTo );
lookup.call();
String country2 = lookup.getCountry();
exchange.setCountry1( country1 );
exchange.setCountry2( country2 );
exchange.call();
return exchange.getRate() * value;
}
}
Derived from
[gof] Facade, [sun] J2EE Session FacadesService Simulator
The service proxy simulates the original service providing the same interface without implementing any communication
Often the real service that should be called by an application is not available. Maybe you're developing in a disconnected environment, or the business process that you have to integrate is not available in the development environment you have to use. The Service Simulator uses a special channel that simulates the communication, so you can test the application without using the real service.
Of course, you can implement a test service that responds to the same interface used by the real service, and then point the application to the test service, but this approach may be too costly in some cases.
The Abstract Service class contains the base functionality for the Service Proxy and hosts a Channel. This component describes the interface of a generic Channel that is implemented in one concrete implementation for each protocol supported (SOAP, XML-RPC, and a REST implementation). In addition to these implementations there is a SimulationChannel, which is basically a no-op.
The client instantiates the Service Proxy, passing an instance of Simulation Channel to it. At each request, the Abstract Services will relay to that channel, which actually does nothing, returning dummy values in place of the response data.
The Simulation Channel can be used to create a test suite for the application.
Sample code
The following class shows an example implementation of the
SimulationChannel class; most of the methods doesn't
do anything, except for getValue(), which simply
returns the XPath expression passed as the parameter:
public class SimulationChannel implements Channel {
public void setParameter( String name, String value ) {
}
public void call() {
}
public String getValue( String expression ) {
return expression;
}
}
This way the client code gets back some test data; but this aspect could be improved, maybe returing the contents of a test data file:
public class SimulationChannel implements Channel {
String xml;
public SimulationChannel( String testFilename )
throws FileNotFoundException, IOException {
//load the xml test file in memory
xml = readFile( testFilename );
}
public void setParameter( String name, String value ) {
}
public void call() {
}
public String getValue( String expression ) {
return XPathEvaluator.evaluate( xml, expression );
}
}
Derived from
[gof] Strategy, [fowler] Special Case
References
- [gof] Gamma et.alt., "Design Patterns", Addison-Wesley 1995
- [sun] SUN Microsystems, "J2EE Core Patterns", Prentice-Hall 2001
- [fowler] Martin Fowler, "Patterns of Enterprise Application Architecture", Addison-Wesley 2003
Have you had experience with similar patterns? Share your comments and questions in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
2006-12-24 10:34:55 Khaled_Bizri [Reply]
Unbelievable...
RPC? REST? Are these SOA protocols?
Interesting way of looking at 'tight coupling' in a loose way!...
The article is out of date and is unawares of existing standards in adopting and implementing SOA. It probably because of the lack of experience in doing so in the field.
most of the patterns are no patterns, since they are supplied one way or the other by the underlying standards-based SOA layers.
If I had a developer reinventing 6-year old artifacts in place in most vendor products, I would probably take a closer look at his work and consider his future in my team! PERIOD.
- Nice Article
2008-07-03 11:49:27 Arvi_23 [Reply]
To the comment on the commenter's comments below,
U should consider your decisions first, if they are rightly made or not, before you act on them. you were right that this is a composite of patterns already existing, as it is already quoted that way in the references section, but your decision about making comments wrt the developer experience , is fast and irrational. why ? here's the reason.. you read this article somewhere close to the beginning of 2007, and the article was written somewhere around mid 2004.Which means the work taken to analysis preceded that time frame, and by the time you read it ie close to 2007 (dec 06), there were many patterns in existence.these articles actually paved the way for better understanding of the architectural principles you became aware of in 2007, or sometime prior to that.So before blurting out fastidious comments, try implementing a filter in your region between the brain and the cognitive impulses taken forward. Its amazing if someone on your team is still listening to the decisions u make !!
- Nice Article : Contd
2008-07-03 11:51:00 Arvi_23 [Reply]
Commenter Above my reply to his post.
- Nice Article : Contd
- Nice Article
- Proxies and WSDL
2004-07-25 18:45:21 wrschneider99 [Reply]
It's worth mentioning that if you have a WSDL document describing a web service, it should be possible to automatically generate a proxy from WSDL for the language/platform of your choice.
