Web services approach to a service-oriented architecture
Web services implement a service-oriented architecture (SOA), making functional building blocks accessible over standard Internet protocols that are independent from platforms and programming languages. These services can be new applications or just wrapped around existing legacy systems to make them network-enabled. A service can rely on another service to achieve its goals.
Each SOA building block can play one or more of three roles...
- Service provider
The service provider creates a Web service and possibly publishes its interface and access information to the service registry. Each provider must decide which services to expose, how to make trade-offs between security and easy availability, how to price the services, or, if they are free, how to exploit them for other value. The provider also has to decide what category the service should be listed in for a given broker service and what sort of trading partner agreements are required to use the service.
- Service broker
The service broker, also known as service registry, is responsible for making the Web service interface and implementation access information available to any potential service requestor. The implementer of the broker decides about the scope of the broker. Public brokers are available through the Internet, while private brokers are only accessible to a limited audience, for example, users of a company intranet. Furthermore, the amount of the offered information has to be decided. Some brokers specialize in many listings. Others offer high levels of trust in the listed services. Some cover a broad landscape of services and others focus within an industry. There are also brokers that catalog other brokers. Depending on the business model, brokers can attempt to maximize look-up requests, number of listings or accuracy of the listings.
- Service requestor
The service requestor or Web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its Web services.
Characteristics of the Web service architecture
The presented SOA employs a loose coupling between the participants, which provides greater flexibility in the following ways...
- A client is not coupled to a server, but to a service. Therefore, the integration of the server takes place outside the scope of the client application programs.
- Old and new functional blocks, or applications and systems, are encapsulated into components that work as services.
- Functional components and their interfaces are separate, allowing new interfaces to be plugged in more easily.
- Within complex applications, the control of business processes can be isolated. A business rule engine can be incorporated to control the workflow of a defined business process. Depending on the state of the workflow, the engine calls the respective services.
- Services can be incorporated dynamically during run time.
- Bindings are specified using configuration files and can be easily adapted to new needs.
Properties of a service-oriented architecture
The service-oriented architecture offers the following properties...
- Web services are self-contained.
On the client side, no additional software is required. A programming language with XML and HTTP client support is enough to get you started. On the server side, a Web server and a SOAP server are required. It is possible to Web services-enable an existing application without writing a single line of code.
- Web services are self-describing.
Neither the client nor the server knows or cares about anything besides the format and content of request and response messages (loosely coupled application integration). The definition of the message format travels with the message; no external metadata repositories or code generation tool are required.
- Web services can be published, located, and invoked across the Internet.
This technology uses established lightweight Internet standards such as HTTP. It leverages the existing infrastructure. Some additional standards that are required to do so include SOAP, WSDL, and UDDI.
- Web services are language-independent and interoperable.
Client and server can be implemented in different environments. Existing code does not have to be changed in order to be Web service enabled. In this redbook, however, we assume that Java is the implementation language for both the client and the server side of the Web service.
- Web services are inherently open and standard-based.
XML and HTTP are the major technical foundation for Web services. A large part of the Web service technology has been built using open-source projects. Therefore, vendor independence and interoperability are realistic goals this time.
- Web services are dynamic.
Dynamic e-business can become reality using Web services because, with UDDI and WSDL, the Web service description and discovery can be automated.
- Web services are composable.
Simple Web services can be aggregated to more complex ones, either using workflow techniques or by calling lower-layer Web services from a Web service implementation. Web services can be chained together to perform higher-level business functions. This shortens development time and enables best-of-breed implementations.
- Web services build on proven mature technology.
There are a lot of commonalities, as well as a few fundamental differences to other distributed computing frameworks. For example, the transport protocol is text based and not binary.
- Web services are loosely coupled.
Traditionally, application design has depended on tight interconnections at both ends. Web services require a simpler level of coordination that allows a more flexible re-configuration for an integration of the services in question.
- Web services provide programmatic access.
The approach provides no graphical user interface; it operates at the code level. Service consumers need to know the interfaces to Web services but do not need to know the implementation details of services.
- Web services provide the ability to wrap existing applications.
Already existing stand-alone applications can easily be integrated into the service-oriented architecture by implementing a Web service as an interface.
See Also
Web services business models supported