| Early on in the Web services technology evolution, we noticed a pattern. Each time we applied Web services technologies to an application integration problem, a pattern emerged. We called this pattern service-oriented architecture ( SOA ). SOA is a simple concept, which makes it applicable to a wide variety of Web services situations. Figure 1.1 depicts the main roles and operations in an SOA. Figure 1.1. Service-oriented architecture.  Any service-oriented architecture contains three roles: a service requestor  , a service provider , and a service registry : -
A service provider is responsible for creating a service description , publishing that service description to one or more service registries, and receiving Web service invocation messages from one or more service requestors. A service provider, then, can be any company that hosts a Web service made available on some network. You can think of a service provider as the "server side" of a client-server relationship between the service requestor and the service provider. -
A service requestor is responsible for finding a service description published to one or more service registries and is responsible for using service descriptions to bind to or invoke Web services hosted by service providers. Any consumer of a Web service can be considered a service requestor. You can think of a service requestor as the "client side" of a client-server relationship between the service requestor and the service provider. -
The service registry is responsible for advertising Web service descriptions published to it by service providers and for allowing service requestors to search the collection of service descriptions contained within the service registry. The service registry role is simple: be a match-maker between service requestor and service provider. Once the service registry makes the match, it is no longer needed in the picture; the rest of the interaction is directly between the service requestor and the service provider for the Web service invocation. Each of these roles can be played by any program or network node. In some circumstances, a single program might fulfill multiple roles; for example, a program can be a service provider, providing a Web service to downstream consumers as well as a service requestor, itself consuming Web services provided by others. An SOA also includes three operations: publish , find , and bind . These operations define the contracts between the SOA roles: -
The publish operation is an act of service registration or service advertisement. It acts as the contract between the service registry and the service provider. When a service provider publishes its Web service description to a service registry, it is advertising the details of that Web service to a community of service requestors. The actual details of the publish API depend on how the service registry is implemented. In certain simple or "direct publish" scenarios, the service registry role is played by the network itself, with publish being simply an act of moving the service description into a Web application server's directory structure. Other services registry implementations , such as UDDI, define a very sophisticated implementation of the publish operation. -
The find operation is the logical dual of the publish operation. The find operation is the contract between a service requestor and a service registry. With the find operation, the service requestor states a search criteria, such as type of service, various other aspects of the service such as quality of service guarantees , and so on. The service registry matches the find criteria against its collection of published Web service descriptions. The result of the find operation is a list of service descriptions that match the find criteria. Of course, the sophistication of the find operation varies with the implementation of the service registry role. Simple service registries can provide a find operation with nothing more sophisticated than an unparameterized HTTP GET. This means the find operation always returns all Web services published to the service registry and it is the service requestor's job to figure out which Web service description matches its needs. UDDI, of course, provides extremely powerful find capabilities. -
The bind operation embodies the client-server relationship between the service requestor and the service provider. The bind operation can be quite sophisticated and dynamic, such as on-the-fly generation of a client-side proxy based on the service description used to invoke the Web service; or it can be a very static model, where a developer hand-codes the way a client application invokes a Web service. The key to SOA is the service description. It is the service description that is published by the service provider to the service registry. It is the service description that is retrieved by the service requestor as a result of the find operation. It is a service description that tells the service requestor everything it needs to know in order to bind to or invoke the Web service provided by the service provider. The service description also indicates what information (if any) is returned to the service requestor as a result of the Web service invocation. Each time a service-oriented architecture is deployed, there might be different technologies to fulfill each role. Chapter 7, "Discovering Web Services," discusses various options for implementing a service registry and goes into great detail on the UDDI service registry technology. Chapter 6, "Describing Web Services," discusses service description and how a service description can be used to automate the task of building a client-side proxy to the Web service and a server-side skeleton to dispatch the Web service invocation to the target Web service implementation. Chapters 3 and 4, "Simple Object Access Protocol (SOAP)" and "Creating Web Services," focus on the use of SOAP to fulfill the bind operation; Chapter 5, "Using SOAP for e-Business," details how the bind can be made ready for e-business. |
