Patterns: Implementing Self-Service in an SOA Environment

Chapter 10. Web services scenario 301

10.3 Applying the design guidelines

In this section we describe the architecture or design decisions that went into

building our sample Web services application. This sample application is an

extension of the ITSOMart application. We use Web services to communicate

between the ITSOMart and the CreditCheck and Delivery Enterprise system.

There are several architectural decisions that go into designing Web service

providers and requesters. These include:

򐂰 Transmission pattern

򐂰 SOAP messaging mechanism

򐂰 Static or dynamic Web services discovery

򐂰 Synchronous versus asynchronous Web services

򐂰 Message structure

򐂰 Mediation

For a complete discussion of application design considerations when developing

Web services applications, see 7.3, “Design guidelines for Web services” on

page 163.

Transmission pattern

Our first task was to define a request-response transmission pattern. In this

pattern, the Web service receives a single request, sends a single response, and

then closes the session. This is an appropriate pattern for our case, where the

ITSOMart application simply requests a credit rating from an enterprise system

and receives a response with Web services.

SOAP messaging mechanism and synchronous pattern

The SOAP messaging mechanism we selected in our application is the RPC

mechanism. Our choice was between using the Remote Procedure Call (RPC)

mechanism or the message-oriented communication mechanism. We decided

on RPC because this is the simplest and most straightforward method. It is also

the most commonly used today. Also, we made the assumption that this would be

a synchronous message transfer and we did not have a need for a delivery

confirmation. The message-oriented communication mechanism is most

appropriate for asynchronous or confirmed delivery types of scenarios. Since our

application had no need for these features, the RPC messaging mechanism was

the most appropriate.