Copyright Notice

Some material in this lecture is adapted from the teaching materials of the book “Web Services: Concepts, Architectures and Applications” and is thus Copyright © 2003 Gustavo Alonso, ETH Zürich and/or Copyright © 2004 Springer-Verlag Berlin Heidelberg.

All other material is Copyright © 2006 Kenneth M. Anderson

Web Services

We look at Web services as a way to expose the functionality of an information system and make it available through standard Web technologies. The use of standard technologies reduces heterogeneity, and is therefore key to facilitating application integration. Furthermore, we show that Web services naturally enable new computing paradigms and architectures, and are specifically geared toward service-oriented computing, a paradigm often touted in the past but never quite realized.
    — Introduction to Chapter 5 of our Textbook

• Defining Web Services
• Motivating Web Services
• Web Services Technologies
• Web Services Architecture

Defining Web Services

• Generic: Any application accessible to other applications over the Web
  • Very open definition, almost any URL becomes a “Web service” under this definition
• UDDI consortium: Web services are self-contained, modular business applications that have open, Internet-oriented, standards-based interfaces
  • Better, but still not specific enough; plenty of “business speak”
• W3C: A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols
  • Slightly better, we now know that URIs and XML are involved (somehow) and that services are similar to components with interfaces that can be defined, described, and discovered
• Wikipedia: According to the W3C, a Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface that is described in a machine-processable format such as WSDL. Other systems interact with the Web service in a manner prescribed by its interface using messages, which may be enclosed in a SOAP envelope, or follow a REST approach. These messages are typically conveyed using HTTP, and normally comprise XML in conjunction with other Web-related standards. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer.
  • Much more specific, appears to reference a W3C definition that is newer than the one used in our textbook

Motivating Web Services

• When discussing EAI, we presented an example consisting of a supply chain within a single company; lets examine this same scenario when the supply chain is split among multiple companies

• B2B processes are carried out manually via Web, fax, or e-mail
• Problems facing B2B process automation include
  • in cross-organization integration, where does the middleware live?
    • need a third-party organization to host the middleware
    • all other parties must agree to use this middleware

• • trust between companies is low (sometimes non-existent)
  • businesses want to retain autonomy (not be dependent on other companies)
  • confidentiality of business transactions (companies do not want to store them on shared middleware)
• As a result, companies that want to do this, need to adopt point-to-point solutions

• This approach, unfortunately, does not scale well.

• These limitations are driven by the fundamental assumption behind conventional middleware that the middleware platform can be centralized and is trusted by the components to be integrated.
• The emergence of Web technologies with its standard interaction protocol (HTTP) and its standardized data formats (first, HTML, and now XML) has now set the stage to provide conventional middleware services in a B2B environment over the Web via the use of Web services technologies.

B2B Integration with Web Services

• There are three aspects of Web services that enable the resolution of some of the limitations discussed on the previous slide:
  • Service-Oriented Architectures
  • Redesigned Middleware Protocols
  • Standardization
• Software as Service: A software service is a software object with a stable, published interface that can be invoked by other software objects. In the case of Web services, these invocations occur via Web-based protocols (HTTP or SOAP) using Web-based data formats (XML). Web services assume that services are loosely-coupled (i.e. they have minimal dependencies) and are typically defined, developed, and deployed by different companies. This assumption leads to a world view that “everything is a service” and helps to realize the vision of service-oriented architectures in which software applications are created by combining multiple services. We are starting to see this view realized with the deployment of services that make use of SOAP, WSDL, and UDDI.
• Middleware Protocols: Conventional middleware protocols, such as two-phase commit, were designed based on assumptions that do not hold in cross-organizational interactions. In order to provide conventional middleware services in a Web services setting, these protocols need to be redesigned to work in a peer-to-peer fashion without assuming the need for a centralized manager. Work in this area is quite young; some specifications are working their way through the standards process, for instance.
• Standardization: OASIS and the W3C are playing the role of standards organizations attempting to standardize all aspects of the Web Services domain. They are attempting to recreate the success that standardization played in making the Web itself a globally-pervasive technology. Lack of standards hindered conventional middleware integration for years, so this aspect to Web services is extremely important.
• The following figure summarizes how these aspects will combine to enable B2B integration via Web services

Web services and EAI

• The ultimate goal of Web services is to make it easy for companies to expose their local information systems in a controlled manner.
• In particular, if this goal is achieved, it would allow Web services to be used to enable EAI across companies or within companies but without the need for adaptors.
• Across companies, Web services allow clients to access internal information systems in a standardized fashion

• Within a single company, the standardized interfaces of Web services would enable EAI without the need for expensive adaptors (the web service interface would take the place of adaptors)

• The above figure is similar to this diagram seen in our last lecture that was discussing conventional EAI; the differences are that no adaptors are needed as long as the message broker is “Web services Aware”

Web Services Technologies

• Service Description
  • What is a service?
  • In conventional middleware, service description is based on interfaces and IDLs. The semantics of the operations in these interfaces and the order in which they are to be invoked are assumed to be known by the team developing the middleware application. The properties of the service are also influenced by the middleware being used and since this is known in advance is not specified explicitly
  • In web services, service description is also based on interfaces but many of the implicit parameters for services of conventional middleware now need to be made explicit in the Web services context
  • As such, service description is accomplished via a “stack” of specification languages

• • Base Language: XML (used by all higher languages)
  • Interfaces: A language used to describe the interface of a Web service. WSDL is the dominant proposal in this area
  • Business Protocols: The order in which operations of a service should be invoked to achieve business-related goals. No clear dominant proposal in this area: two contenders are WSCL and BPEL
  • Properties and Semantics: Specification of non-functional properties. UDDI is the dominant proposal in this area.
  • Verticals: Standards which specify the above information for a particular domain, such as health care or business transactions. RosettaNet is cited as an example of a vertical standard in the textbook.
• Service Discovery
  • Service descriptions need to be stored in a service directory to enable clients to find services that they can use
  • This is known as service discovery and UDDI is the dominant specification for defining the APIs of service directories in the Web services world
• Service Interactions
  • Once a client has been connected to a service, standards are needed to specify the ways in which these two entities interact

• • Transport: HTTP
  • Messaging: SOAP (specifies the on-the-wire format used to exchange messages between a client and a service)
  • Meta-Protocols: WS-Coordination how to coordinate the interactions between a client and a service
  • Middleware Protocols: How do we add services that conventional middleware provided to a Web Services environment. WS-Transaction is the first protocol being defined in order to add support for transactions when a client needs to access more than one web service with transaction semantics.
• Service Composition
  • What information do we need in order to combine existing services into new services
  • Similar (but not exactly) to the “mashups” that we see in the Web 2.0 world, where the services of multiple companies are being combined to create an information display not possible when using the services in isolation

Web Services Architecture

• Two aspects: internal and external
• Internal: how do we connect a Web service to a company's information systems
• External: how do we connect a client with a Web service

• With respect to the internal architecture, Web services are viewed as wrappers of existing information systems. We need a middleware layer that can connect Web services to a company's existing middleware platform.

• With respect to the external architecture, Web services assume the existence of a third-party directory service that is used for service discovery. Once such a service is in place, then the external architecture looks like this:

• Since it would be difficult to scale this approach (assuming the existence of a third-party manager) for other middleware characteristics (such as support for transactions), it is assumed that in the future, individual Web services will each provide these managers (in some fashion) and that these individual managers will coordinate in a peer-to-peer fashion to achieve the desired effects.

What's Next?

• On Thursday, we will have student presentations on:
  • SOAP
  • WSDL
  • UDDI
• Over the next couple of lectures, we will continue to explore the Web services topic by looking at specific examples
  • I need volunteers to play with existing Web services and do short (10-15 minutes) presentations on them. This can include:
    • IDE support: Sun's NetBeans, IBM's Eclipse, Microsoft's Visual Studio
    • Web Service Deconstruction: How does a particular Web service work... what does it do, how is its API used, etc.
    • Other Web Service Infrastructure: I'm going to cover Axis 2, but there are other toolkits
    • Support for Web services in scripting languages and/or programming languages
    • Your idea here!