168 Patterns: Implementing Self-Service in an SOA Environment
Figure 7-11 Web service requester architecture
7.3.2 Web services design considerations
This section describes architectural decisions that you need to make when
designing Web service providers and requesters. We describe each of the
decisions that need to be made and then talk about some of the technical issues
involved in these decisions. We then give some guidelines for system architects
on how to make the appropriate choices for a given application.
Transmission patterns
The first design option we should look at for designing Web services is the
Transmission pattern we expect to use. These patterns represent different types
of operations that can be defined in a WSDL file. The four basic patterns are:
Request-response
One-way
Solicit-response
Notification operation
Request-response
The request-response transmission primitive is shown in Figure 7-12 on
page 169.
Model
Business Logic
Enterprise
Applications
Enterprise
Data Sources
Page
Construction
(JSP)
View
Controller
Interaction
Controller
(Servlet)
Command
Bean
Web Service
Consumer
Result
Bean
View
Bean
Web Service
Provider
Chapter 7. Application and system design guidelines 169
Figure 7-12 Request-response transmission
One-way
The one-way transmission primitive is shown in Figure 7-13.
Figure 7-13 One-way transmission
Solicit-response
The solicit-response transmission primitive is shown in Figure 7-14 on page 170.
Note: A request-response operation is an abstract notion. A particular binding
must be consulted to determine how the messages are actually sent: Within a
single communication (such as a HTTP request/response), or as two
independent communications (such as two HTTP requests).
Web Service
Requester
Web Service
Provider
Web Service
Requester
Web Service
Provider
170 Patterns: Implementing Self-Service in an SOA Environment
Figure 7-14 Solicit-response transmission
Notification operation
The notification operation transmission primitive is shown in Figure 7-15.
Figure 7-15 Notification operation transmission
SOAP messaging mechanisms
The next design point in architecting a Web service is to choose the SOAP
messaging mechanism to use. Figure 7-16 on page 171 shows the two general
categories of Web services SOAP messaging mechanisms:
SOAP RPC-based Web services
SOAP message-oriented Web services
Web Service
Requester
Web Service
Provider
Web Service
Requester
Web Service
Provider
Chapter 7. Application and system design guidelines 171
Figure 7-16 SOAP messaging operations
RPC versus message-oriented
The advantages and disadvantages of the SOAP RPC approach versus the
SOAP message-oriented Web service approach can be summarized as follows:
SOAP RPC advantage:
Simpler development:
SOAP RPC disadvantages
Requester is too dependent on the availability of the Web service provider
SOAP message-oriented advantages:
– Less dependency on the Web service provider availability
– Works well for exchanging large documents
– Works well from a nonrepudiation perspective because documents can be
signed digitally and stored at both ends
– Enables extended enterprise electronic workflow and business process
integration using asynchronous integration
SOAP message-oriented disadvantage:
Relatively more complex development because it uses assured delivery of
asynchronous messages and can require compensating transactions.
Model
Business Logic
Business
Objects
XML
SOAP
Message
Enterprise
Applications
Enterprise
Data Sources
External
Applications
For example,
Business
Partner
External
Web Service
Consumer
XML
SOAP
Message
Message
Router
RPC
Router
Web Service
Provider Bean
XML
SOAP
Message
172 Patterns: Implementing Self-Service in an SOA Environment
Static versus dynamic Web services discovery
Our next design point is to decide if the Web service requester will use static or
dynamic discovery of available Web services. The requester has to begin with
the WSDL file that describes the interface and implementation specification of
the Web service to be invoked. This WSDL file can be retrieved dynamically
using a service registry, or statically, as shown in Figure 7-17.
Figure 7-17 Web services discovery methods
Three types of discovery methods for requesters can be identified. They import
interface and implementation information at different points in time (build time
versus. runtime):
Static service
No public, private, or shared UDDI registry is involved. The service requester
obtains a service interface and implementation description through a
proprietary channel from the service provider (an e-mail, for example), and
stores it in a local configuration file.
Provider-dynamic
The service requester obtains the service interface specification from a
public, private, or shared UDDI registry at build time and generates proxy
code for it. The service implementation document identifying the service
provider is dynamically discovered at runtime (using the same or another
UDDI registry).
Service
Requester
Static Service
SOAP
Listener
Service
Provider
Service
Requester
Dynamic Discovery
SOAP
Listener
Service
Provider
Service
Registry
Get Patterns: Implementing Self-Service in an SOA Environment now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
