1. Web Services
Chapter 5

2. Introduction
Web services is 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.
Web services naturally enable new computing paradigms and architectures.
They are specifically geared to service-oriented computing, a paradigm often touted in the past but never quite realized.

3. Web Services Definitions
An application accessible to other applications over the Web.
Very open definition, under which just about anything that has a URL is a Web service.
It can include a CGI script.
It can also refer to a program accessible over the Web with a stable API, published with additional descriptive information on some service directory.

4. Definitions Definition 2 (UDDI consortium)
self-contained, modular business applications that have open, Internet-oriented, standard s-based interfaces.
Emphasizes on the need for being compliant with Internet standards.
They have to be open in the sense that they have published interfaces that can be invoked across the Internet.
Not precise; not clear what is meant by a modular, self-contained business application.

5. Definitions Definition 3 (World Wide Web Consortium W3C):
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.
This definition clarifies accessibility, Internet-oriented standards-based interfaces.
Web services should be “services” similar to those in conventional middleware
Up and running
Described and advertised, to enable binding and interacting
XML is part of the solution

6. Definitions Definition 4 (online technical dictionary Webopedia):
A standardized way of integrating Web-based applications using the XML, SOAP, WSDL, and UDDI open standards over an Internet protocol backbone.
XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available, and UDDI is used for listing what services are available.
This definition is too specific with respect to standards.
These standards do not constitute the essence of Web services technology: the problems underlying Web services are the same regardless of the standards used.
We adopt the W3C definition.

7. Need for B2B Integration
Main issues are the integration of several autonomous and heterogeneous systems and the automation of business processes across these systems.
EAI platforms facilitated this when all the components (though heterogeneous) belonged to one company.
We now address the problem when the components are managed and operated by different companies.
Currently, the “integration” is done manually, by employees who access the internal systems and then communicate with other companies by filling out Web forms or via or fax.
Supply chain example – Fig. 5.1

8. customer supplier warehouse web server internal procurement
requests
internal infrastructure
B2B interactions occur by accessing Web pages, filling Web forms, or via .
internal infrastructure
web server
internal infrastructure
warehouse
Copyright Springer Verlag Berlin Heidelberg 2004

9. Conventional Middleware Limitations
How was the integration done in the conventional middleware platforms?
Refer to Figure 3.10
Middleware was centralized (at least logically), and it was controlled by a single company.
Adopting the same solution here would require that the customer, supplier, and warehouse agree on using and cooperatively managing a certain middleware platform (e.g., a specific message broker, a specific workflow system, and a specific name and directory server) and on implementing a “global workflow” that drives the whole business process.
Refer to Fig. 5.2

10. Copyright Springer Verlag Berlin Heidelberg 2004
WfMS
WfMS adapter
message broker
SmartQuotation
adapter
database
adapter
SmartForecasting
adapter
adapter
XYZ
adapter
SmartQuotation
DBMS applications
XYZ
SmartForecasting
Copyright Springer Verlag Berlin Heidelberg 2004

11. third party message broker customer supplier warehouse WfMS
a “global” workflow is executed here
WfMS adapter
the combination of message broker and adapters enables interoperability
message broker
customer
supplier
customer’s adapters
supplier’s adapters
warehouse
internal procurement
requests
internal infrastructure
warehouse’s adapters
internal infrastructure
internal infrastructure
Copyright Springer Verlag Berlin Heidelberg 2004

12. Limitations
Conventional approach not possible in general setting due to:
Lack of trust between companies
The autonomy each company wants to preserve
The confidentiality of the business processes
A centralized middleware hosted by one of the participating companies or by a third party is not acceptable.

13. An Alternate Solution Point-to-point integration across companies
Two parties agree on a common middleware
Integration through that middleware
Follow this pattern between each pair of companies in a multi-party integration set up.
Then, these different middleware systems need to be integrated too.
Figures 5.3 and 5.4

14. customer supplier warehouse web server internal procurement
requests
internal infrastructure
B2B interactions occur by accessing Web pages, filling Web forms, or via .
internal infrastructure
web server
internal infrastructure
warehouse
Copyright Springer Verlag Berlin Heidelberg 2004

15. third party message broker customer supplier warehouse WfMS
a “global” workflow is executed here
WfMS adapter
the combination of message broker and adapters enables interoperability
message broker
customer
supplier
customer’s adapters
supplier’s adapters
warehouse
internal procurement
requests
internal infrastructure
warehouse’s adapters
internal infrastructure
internal infrastructure
Copyright Springer Verlag Berlin Heidelberg 2004

16. customer supplier message broker message broker XYZ XYZ
customer’s adapters
supplier’s adapters
internal infrastructure
internal infrastructure
Copyright Springer Verlag Berlin Heidelberg 2004

17. customer warehouse another party (XYZ) yet another party (ABC)
supplier
customer
middleware for supplier-customer interaction
middleware for supplier-warehouse interaction
warehouse
middleware for integrating the middleware
middleware for supplier-XYZ interaction
another party (XYZ)
middleware for supplier-ABC interaction
supplier’s adapters
supplier’s adapters
supplier’s adapters
yet another party (ABC)
internal infrastructure
Copyright Springer Verlag Berlin Heidelberg 2004

18. Further Limitations EAI interactions are typically short-lived
Calling a procedure, method or a function
Cross-organizational interactions last longer
Interactions involve course-grained operations lasting several hours or days
Example: the supplier may confirm that the order has been processed only after the requested goods have been physically picked up by a shipping company
Cross-organizational interactions are mostly implemented as asynchronous exchanges
Providing transactional properties is difficult: conventional protocols such as 2PC not applicable – these are the protocols supported by conventional middleware and EAI tools
EAI interactions occur in the same trust domain; cross-organizational interactions occur across different trust domains
There is an implicit lack of trust between interacting entities

19. B2B Integration with Web Services
Three main aspects
1. Service-oriented paradigm
Functionality made available by a company is exposed as a service.
With a stable, published interface that can be invoked by clients
That is, requesting and executing a service involves a program calling another program
Different services are autonomous, independent, and reusable.
Not every service available through the Web is a Web service.
A Web service is a software application with a published and stable programming interface, not a set of Web pages.
Listings of bookstores, restaurants, travel agencies are not Web services, even if their services can be obtained through the Web server of that company.

20. B2B Integration with Web Services
2. Redesign of middleware protocols
To work in peer-to-peer fashion and across companies
No central coordinator due to lack of trust and confidentiality issues
2PC must be designed to work in a fully distributed fashion, with more flexibility in terms of locking resources.
Similarly, redesign interaction and coordination protocols, providing reliability and guaranteed delivery.

21. B2B Integration with Web Services
3. Standardization
Standardize all the different aspects of the interaction, ranging from interface definition languages to message formats and interaction protocols
Does not mean only one specification for each aspect of interaction.
A limited number of specifications will eventually emerge as winners.
Figure 5.5 summarizes how Web services address the B2B integration problem.
Web services are analogous to sophisticated wrappers that encapsulate one or more applications by providing a unique interface and a Web access.
See Figure 5.6.
Web services are made “homogeneous” through standardizations and wrappers.
Web services do not need to be accessed through the Internet.
See Figure 5.7.

22. customer supplier warehouse
languages and protocols standardized, eliminating need for many different middleware infrastructures (need only the Web services middleware)
customer
supplier
Web service
Web service
internal procurement
requests
internal infrastructure
internal infrastructure
interactions based on protocols redesigned for peer to peer and B2B settings
Web service
internal functionality made available as a service
internal infrastructure
warehouse
Copyright Springer Verlag Berlin Heidelberg 2004

23. wide area network (Internet)
Web service
client
Web service
Web service
wide area network (Internet)
middleware
middleware
internal service
internal service
internal service
internal service
Company A (provider)
Company B (client)
Copyright Springer Verlag Berlin Heidelberg 2004

24. Copyright Springer Verlag Berlin Heidelberg 2004
Company A (or a LAN within Company A)
integrating application (contains the composition logic)
Web service-enabled broker
sendmail application
SmartQuotation
DBMS applications
SmartForecasting
XYZ
assumes all back-end systems are accessible as Web services
Copyright Springer Verlag Berlin Heidelberg 2004

25. Web Services Technology
1. Service Description
In conventional middleware, based on interfaces and interface definition languages
Semantics of the different operations, the order in which they should be evoked, and other (possibly nonfunctional) properties are assumed to be known in advance by the programmer developing the clients.
The middleware platform defines and constrains many aspects of the service description and binding process that are therefore implicit, and they do not need to be specified as part of the service description.
In Web services and B2B interactions, such implicit context is missing.
Therefore, service descriptions must be richer and more detailed, covering aspects beyond the mere service interface.
Figure 5.8 illustrates the different aspects.

26. Copyright Springer Verlag Berlin Heidelberg 2004
vertical standards
properties and semantics
business protocols
directories
interfaces
common base language
Copyright Springer Verlag Berlin Heidelberg 2004

27. Different Layers Common base language Interfaces Business protocols
A common meta-language that can be used as the basis for specifying all the different languages necessary to describe the different aspects of the service.
XML is used for this purpose
Interfaces
Basic interface definition language, and additional features
Different interaction modes, the XML schema-driven type system
Description of the context (since there is no implicit context)
Web Services Description Language (WSDL)
Business protocols
Describe rules that govern conversations (e.g., request quotes, order the goods, finally make payments), stating which conversations are valid and understood by the service.
Specify not only the interface but also the business protocols the service supports.
Web Services Conversation Language (WSCL) and the Business Process Execution Language for Web Services (BPEL4WS).

28. Different Layers Properties and semantics Verticals
Additional layers of information, apart from the functionality, to facilitate binding in autonomous and loosely-coupled settings
Examples: the cost or the quality of the service, a textual description of the service such as the return policy when making a purchase
Information crucial for using the service but not part of the interface of the service
Universal Description, Discovery, and Integration (UDDI) specification
This specification describes how to organize the information about a Web service and how to build repositories where such information can be registered and queried.
Verticals
Complements the previous layers by tailoring them to concrete applications, further facilitating the use of standard tools for driving the exchanges
Define specific interfaces, protocols, properties, and semantics that services offered in certain application domains should support.
They enable the development of client applications that can interact in a meaningful way with any Web service that is compliant with a certain vertical standard.

29. Service Discovery Service descriptions stored in a service directory
Service designers register new services, service users search for and locate services
Service discovery can be done both at design-time, by browsing the directory and identifying relevant services, and at run-time, using dynamic binding techniques.
Directories can be hosted and managed by a trusted entity (centralized approach), or each company can host and manage a directory service (peer-to-peer approach).
In both cases, APIs and protocols are needed for clients to interact with the directory service or for the local directory services to exchange information among themselves in a peer-to-peer fashion.
UDDI specification defines standard APIs for publishing and discovering information into service directories.
It also describes how such directories should work.

30. Service Interactions
Service description and discovery are concerned with static and dynamic binding.
Once the binding problem has been addressed, a set of abstractions and tools that enable interactions among web services is needed.
These abstractions take the form of a set of standards that address different aspects of interactions at different levels.
See Figure 5.9.
These protocols are useful for any Web service and are therefore implemented by the Web services middleware.
They are transparent (for the most part) to the developers.

31. Copyright Springer Verlag Berlin Heidelberg 2004
middleware properties (horizontal protocols)
protocol infrastructure (meta-protocols)
basic and secure messaging
transport
Copyright Springer Verlag Berlin Heidelberg 2004

32. Service Interaction Stack
Transport
Most common transport protocol is HTTP.
Messaging
A standard way to format and package the message to be exchanged.
Simple Object Access Protocol (SOAP) is used.
It simply specifies a generic message template to add to the top of the application data.
Additional specifications standardize the way to use SOAP to implement particular features.
For instance, WS-security describes how to implement secure exchanges with SOAP.

33. Service Interaction Stack
Protocol infrastructure (meta-protocols)
Much of the software required to support business protocols can be implemented as generic infrastructure components.
For example, the infrastructure can maintain the state of the conversation between a client and a service, associate messages to the appropriate conversation, or verify that a message exchange occurs in accordance to the rules defined by the protocols.
Execution of meta-protocols, which are protocols whose purpose is to facilitate and coordinate the execution of business protocols.
For example, before the actual interaction can begin, clients and services need to agree on what protocol should be executed, who is coordinating the protocol execution, and how protocol execution identifiers are embedded into messages to denote that a certain message exchange is occurring in the context of a protocol.
WS-Coordination is a specification that tries to standardize these meta-protocols and the way WSDL and SOAP should be used for conveying information relevant to the execution of a protocol.

34. Service Interaction Stack
Middleware (horizontal) protocols
Providing the same properties as conventional middleware, e.g., reliability and transactions.
Since Web services and their supporting infrastructure are distributed in nature, middleware properties that go beyond basic communication are achieved by means of standardized peer-to-peer protocols, called horizontal since they are generally applicable to many Web services.
For example, reliability and transaction require the execution of protocols (e.g., 2PC) among the interacting entities.
These horizontal protocols can also be supported by meta-protocols.
WS-transaction builds upon WS-Coordination to define how to implement transactional properties when dealing with Web services.

35. Combining Web Services - Composition
A Web service implemented by invoking other Web services is called a composite service.
A Web service implemented by accessing the local system is called a basic service.
Whether a Web service is basic or composite is irrelevant to the clients.
All Web services can be described, discovered, and invoked the same way.
Need for providing service composition technologies as part of the Web services middleware.
BPEL4WS seems to be emerging as the leading service composition language.

36. Web Services Architecture
Two facets
Internal middleware and internal architecture
Exposing internal operations so that they can be invoked through the Web.
Receive requests through the Web and pass them to the underlying system.
The problems are analogous to those encountered in conventional middleware.
External middleware and external architecture
Integrating different Web services.
Three components of the external architecture
Centralized brokers – analogous to the centralized components in conventional middleware that route messages and provide properties to the interactions (such as logging, transactional guarantee, name and directory services, and reliability).
Protocol infrastructure – components that coordinate the interactions among the Web services and implement the peer-to-peer protocols.
Service composition infrastructure – set of rules that support the definition and execution of composite services.

37. external architecture internal architecture
client
Company D (client)
Company A (provider)
Web service
Web service interface
Access to internal systems
Web service
external architecture
internal architecture
Company C (provider)
middleware
internal service
internal service
Web service
Web service
Company B (provider)
Copyright Springer Verlag Berlin Heidelberg 2004

38. Internal Architecture
View as yet another tier on the top of the other tiers of the enterprise architecture.
See Figure 5.11.
When multiple middleware instances are stacked on top of each other, the middleware used at each level need not be the same.
The important point is to have compatible service abstractions or to make them compatible using wrappers.
The middleware simply acts as the glue necessary to make all the components in a given level interact with each other to form services that can be used by clients or higher levels in the hierarchy. Web services play the same role.
See Figure 5.12.
Implementation does not occur at the Web services layer, but within conventional middleware.
Web services are just wrappers. They invoke internal services that implement whatever application logic is needed, and then collect the results.

39. Copyright Springer Verlag Berlin Heidelberg 2004
other tiers
service interface
integration logic
middleware
resource manager
middleware
service interface
integration logic
resource manager
middleware
service interface
integration logic
Copyright Springer Verlag Berlin Heidelberg 2004

40. conventional middleware (includes middleware services)
Company A (service provider)
Web service interface
access to internal systems
clients from other companies
Web services middleware (internal)
service interface
integration logic
Conventional middleware provides lots of services (load balancing, transaction support, etc).
Current Web services middleware is quite poor in this respect.
conventional middleware (includes middleware services)
other tiers
other tiers
Copyright Springer Verlag Berlin Heidelberg 2004

41. External Architecture
Integrating the “wrappers”.
Where should this middleware reside?
One solution is to implement middleware as a peer-to-peer system where all participants cooperate to provide name and directory services.
Not clear how to provide the necessary degree of reliability and trustworthiness.
The other solution is to introduce intermediaries or brokers acting as the necessary middleware.
Assuming that we can find a site in the network we can trust and is reliable enough.
currently only one type of Web services broker that has been standardized and used, though to a very limited extent: the name and directory server.
Figure 5.13 shows the external architecture with respect to centralized components, as understood today.

42. Web services middleware (internal) Web services middleware (internal)
Company A (service requester)
Company B (service provider)
Web services middleware (internal)
Web services middleware (internal)
Web service client
Web service
3. interact
other tiers
other tiers
2. find
1. publish the service description
the abstraction and infrastructure provided by the registry are part of the external middleware
service descriptions
Company C (directory service provider)
Copyright Springer Verlag Berlin Heidelberg 2004

43. Other Web Services Middlewares
Other middleware features such as transaction management cannot be centralized.
They need more trust than for a directory service.
A hypothetical transaction broker can be implemented as a peer-to-peer system
Each service requestor will have its own transaction manager.
When the service requestor invokes Web services in a transactional manner, its own transaction manager becomes responsible for orchestrating the execution so that the transactional semantics are preserved.
Other middleware properties are also, in general, provided through peer-to-peer protocols and through an infrastructure that supports the execution of such protocols.
Such an infrastructure is part of the external architecture, but is typically owned and controlled by the service requestor and by the service provider, not by a third party.
See Figure 5.14
Service composition tools are another ingredient of external Web services architecture.

44. external middleware Company C (directory service provider)
Company A
(service requester)
external middleware
Company B
(service provider)
Web service client
Web service
transaction mgmt
transaction mgmt
internal middleware
internal middleware
other protocol infrastructure
other protocol infrastructure
other tiers
composition engine
composition engine
other tiers
service descriptions
Company C
(directory service provider)
Copyright Springer Verlag Berlin Heidelberg 2004