Web services approach to a service-oriented architecture

 

+

Search Tips   |   Advanced Search

 

You can use Web services to implement a SOA.

Web services make 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 assume one or more of three roles:

• Service provider

  Creates a Web service and possibly publishes its interface and access information to the service registry. Each provider decides...

  • 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
  • Which category to list the service in
  • What sort of trading partner agreements are required to use the service.

• Service broker

  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.

  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

  The service requestor or 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.

.

The presented SOA illustrates a loose coupling between the participants, which provides greater flexibility in the following ways:

• 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 adapted to new needs.

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 enable an existing application for Web services 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 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, SOAP, Web Services Description Language (WSDL), and UDDI.

• Web services are language-independent and interoperable

  The 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

  Dynamic e-business can become reality using Web services because with UDDI and WSDL you 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 integrate into the SOA by implementing a Web service as an interface.

---

 

Related concepts

Web services business models supported
Web services
Service-oriented architecture
Overview: Online garden retailer Web services scenarios

 

Related tasks

Task overview: Implementing Web services applications
Enabling Web services through service integration technologies
WS-Notification - publish and subscribe messaging for Web services