NIH Enterprise Architecture Home

Web Services Brick

Description

Web services are not really a technology; they represent software components and a common set of standards supported by multiple, different technologies and vendors. Web services are Web-based services that use any one or more of three related XML-based standards including:

  • SOAP - Simple Object Access Protocol, request-reply protocol for inter-program communication.
  • WSDL - Web Services Description Language, an interface-definition syntax.
  • UDDI - Universal Description, Discovery and Integration, defines how a directory is used to register Web services.

Web services can operate over Internet protocols. These include TCP/IP, the standard Internet transport; secure sockets; File Transfer Protocol (FTP) for uploading and downloading files to and from the Internet; Hypertext Transmission Protocol (HTTP) and secure HTTP (S-HTTP) for sending information over the Web; and Simple Mail Transfer Protocol (SMTP) for e-mail messaging; and even message-oriented middleware (MOM) and Java Message Service (JMS). The second fundamental technology is Extensible Markup Language (XML), which is the language used to create the messages, files, metadata and documents that define and describe Web services. In addition to HTTP, Web services make use of one or more of these technologies:

  • SOAP lets one application invoke a remote procedure call (RPC) on another application, or pass structured data to a remote location using XML messages and the Web.
  • WSDL is a formal XML vocabulary for describing Web services, their interfaces and basic implementation information for use in Web services registries and repositories.
  • UDDI is a platform-neutral registry for publishing, querying, finding and invoking Web services via metadata and interfaces.

Taken together, SOAP, WSDL and UDDI form the Web services technology canon that fits atop the XML and Internet infrastructure. Here are some of the many sources for Web services:

  • Applications written in Java J2EE
  • Applications written in Microsoft.NET (all Common Language Runtime1 languages)
  • Applications developed with ColdFusion MX
  • “Wrapped” service programs from legacy applications
  • Integration Broker Suite (IBS)
  • Commercial off-the-shelf applications
  • Commercial service providers (Internet)

The beauty of Web services today is in their simplicity. Eventually, however, complexity will creep in. Vendors (and enterprises) are developing additional layers to the existing Web services stack to address perceived (and real) issues, such as security, transaction management, user interface development, collaborative and peer-to-peer environments, business-to-business (B2B) interactions and more.

The emerging stack comes in multiple flavors, depending on the vendor, industry association or standards organization that is authoring the additions. There will be recurring attempts to build an entire stack of Web services standards that might satisfy every requirement that an enterprise might foresee, and without exception, these attempts will fail due to the vastness of their scope. Electronic business XML (ebXML) might be one such example.

More importantly, Web services standards need to fit within a larger framework that can support comprehensive enterprise requirements.

Brick Information

Tactical

(0-2 years)

Strategic

(2-5 years)

  • ebXML
  • SOAP
  • UDDI
  • WSDL
  • WS-Security and related standards
  • XML
  • XML Schema Definition (XSD)
  • Additional standards as they mature
  • ebXML
  • SOAP
  • UDDI
  • WSDL
  • WS-Security and related standards
  • XML
  • XSD

Retirement

(To be eliminated)

Containment

(No new development)

 

 

  • POX (Plain Old XML over HTTP)

 

Baseline

(Today)

Emerging

(To track)

  • ebXML
  • POX
  • SOAP
  • UDDI
  • WSDL
  • XML
  • XSD

 

  • Additional Web Services standards as they emerge
  • RelaxNG
  • REST (REpresentational State Transfer)
  • RSS (Really Simple Syndication)
  • SCA (Service Component Architecture)
  • WS-BPEL (Business Process Execution Language)
  • WS-Management

Comments

  • Use of POX requires an exception due to the lack of a standard security approach.
  • Tactical and strategic products were selected to leverage NIH's investment in products that are a proven fit for NIH's known future needs. Leveraging baseline products in the future will minimize the operations, maintenance, support and training costs of new products.
  • Some baseline products have been designated retirement and containment. These products are either not as widely or successfully deployed at NIH, or they do not provide as much functionality, value, or Total Cost of Ownership as the selected tactical and strategic products.
  • WS-Security will be used to secure web services. Supporting standards such as XML-Enc, XML-Dsig, and Security Assertion Markup Language (SAML) are also considered part of this standard. Contact OCITA for specific guidance on which specific standards are applicable for new implementations.
  • WS-BPEL is emerging as the prevalent standard for specifying process flows in support of service orchestration (see “Service Orchestration Pattern”). It will be followed closely and is likely to be incorporated into the Strategic category in the future.
  • REST should be considered as a potential programming model for web services in the future, particularly in cases where the focus is on providing information access.
  • RSS is added as an emerging approach. It is not clear how it will be used for application to application integration, other than for simple data exchange.

Time Table

This architecture definition approved on: May 24, 2006

The next review is scheduled in: TBD