Web services approach to a service-oriented architecture
The Web services approach implements SOA. Each SOA building block can assume one or more of three roles:
Service provider Creates a Web service and possibly publishes 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 how to exploit free services for other value. The provider also has to decide which category to list the service in for a given broker service and what sort of trading partner agreements are required to use the service.
Service broker Also known as service registry. Responsible for making the Web service interface and implementation access information available to any potential service requestor. The implementer of the broker decides 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, some decisions need to be made about the amount of the offered information. 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. Some brokers catalog other brokers. Depending on the business model, brokers can attempt to maximize look-up requests, the number of listings or the accuracy of the listings.
The UDDI specification defines a way to publish and discover information about Web services.
Service requester Also known as Web service client. Locates entries in the broker registry using various find operations and then binds to the service provider to invoke one of its Web services. .
Characteristics of the SOA
- A client is coupled 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, so that new interfaces can 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.
- Web services are self-describing.
Neither the client nor the server knows or cares about anything besides the format and content of the 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 and it leverages the existing infrastructure. Some other standards that are required include, 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 change in order to be Web services enabled.
- 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.
- Web services are dynamic.
With UDDI and WSDL one can automate the Web service description and discovery.
- 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 chaining shortens development time and enables best-of-breed implementations.
- 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 supports a more flexible reconfiguration for an integration of the services.
- 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 integrate into the service-oriented architecture by implementing a Web service as an interface.
See Also
Web services business models supported
Web services
Service-oriented architecture
Overview: Online garden retailer Web services scenarios
Related Tasks
Developing Web services applications