Tutorials SOA Web ServicesThe approach of building your SOA with web services as the means of implementation offers several benefits as listed here:
Web services are self-contained in the sense that they do not require any components to be installed on the client side. On the server merely a Servlet engine, an EJB container, or a .NET runtime is required for deploying the service. When the service is deployed and ready to run, a client can consume the service without the need for any software installations on its machine. You can contrast this with other technologies such as DCOM, or RMI where the client stub must be installed on the consumer machine before the client can access the service.
Web services are self-describing. An interface to a (web) service is published through a WSDL document. Such a WSDL document defines the format for the message exchange and the data types used in messages. To consume a service, the client needs to know only about the format and contents of a request and response message.
Web services provide a further abstraction on the existing component technologies based on J2EE, CORBA, DCOM, and so on. Using these various technologies, we create components. The web services compose these components to offer a service to the client. The interface to the components is not exposed to the client. This results in a modular software development resulting in creating a more abstract view of a business service.
Web services are published, located, and invoked over the Web. Web services use standard web protocols. The service description is published using WSDL; the service is located with the help of a UDDI registry and it is invoked using SOAP. All these protocols are web-based.
As web services are based on open XML standards, they are language neutral; a client written in any language can access a web service written in any other language. Web services are platform neutral; the consumer and service may be running on two independent platforms. Web services are transport neutral; the service can be invoked using any standard network protocol.
The web services technology is based on open standards making web services easily interoperable with other web services. These standards are XML-based and are SOAP, WSDL, and UDDI.
Web services can be discovered and consumed at run time, without the need to have any compile-time knowledge of them. In most other technologies, the client needs compile-time knowledge of the component interface. An exception to this is CORBA (Common Object Request Broker Architecture), which provides a DII (Dynamic Invocation Interface) for run-time discovery and invocation of the service. A similar dynamic invocation interface is also available in the Java and .NET platforms.
Web services can be aggregated into a larger service. As seen in the earlier chapters, we can use orchestration engines for composing web services into a larger service. Such orchestration can be coded using well-accepted BPEL (Business Process Execution Language).
Having considered the benefits of web services, we will now look at the patterns that may be applied while creating web services to implement SOA.
First Page: SOA Web Services - Designing Sound Web Services
