Web Services Pattern

Web services are a software concept and infrastructure for program-to-program communication and application component delivery. The Web services concept treats software as a set of services accessible over ubiquitous networks using Web-based standards and protocols. A Web service is a software component that can be accessed by another application (such as a client, a server or another Web service) through the use of generally available, ubiquitous protocols and transports, such as Hypertext Transport Protocol (HTTP). This pattern illustrates the protocols and interactions that are at the core of web services. 

The components of this pattern are:

• Transmission Control Protocol/Internet Protocol (TCP/IP) – Provides the low level communication protocol for web services.
• HTTP – This is the underlying transport protocol used for web services.
• Simple Object Access Protocol (SOAP) – Provides the request-reply semantics used to deliver web services.
• Extensible Markup Language (XML) – The underlying format used for all web services messages. The arguments used in SOAP messages are defined using XML formats to define elements.
• Universal Description, Discovery, and Integration (UDDI) – Provides the means to register and share web services facilitating reuse and configuration management.
• Web Service Definition Language (WSDL) – Provides interface definitions and runtime bindings for web services.

Additional web services standards will be incorporated into NIH's web services stack over time as described in the Web Services brick.

Web services are the preferred communication mechanism between service consumers and service providers in NIH's SOA. Generally HTTP is used as the transport protocol for web services, but Java Message Service (JMS) may also be used to provide enhanced reliability. However, this is only possible when the SOAP client and the SOAP server are Java-based.

Please view the Web Services Pattern below:

• Web services are a key enabler for SOA, providing a platform independent communications mechanism, interface definition language and registry for interoperability between applications.
• The use HTTP(S) as the underlying transport eases security and network configuration to support web services because it leverages the same protocols and ports as web traffic.

• The extent to which UDDI will be required to be used as a runtime mechanism for dynamic service discovery must be determined.
• The specific versions of the standards used and the higher level services that will be used to facilitate web services.
• Specific guidelines for the use of web services and other communications mechanisms. This includes understanding when the use of web services are appropriate and when other communications approaches are appropriate.

Recommended Usage

• When shared reusable services need to be implemented within NIH without impacting performance and security requirements.
• When request-reply service integration is required between heterogeneous platforms.
• When a legacy system must be accessed from NIH's ESB and there is no existing adapter, a web service wrapper may be developed in order to allow the ESB to interact with the legacy system.