Web services approach to a service-oriented architecture

The Web services approach implements a service-oriented architecture (SOA). A major focus of Web services is to 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
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 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
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 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 Universal Description, Discovery and Integration (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.

Service-oriented architecture .

Characteristics of the SOA 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 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 Extensible Markup Language (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.
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 easily integrate into the service-oriented architecture by implementing a Web service as an interface.

Related tasks
Developing Web services applications