Web Services Chapter 5 Introduction Web services is

Web Services Chapter 5

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.

Web Services Definition 1: 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.

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.

Definitions Definition 3 (World Wide Web Consortium W 3 C): 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

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 W 3 C definition.

Need for B 2 B 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 email or fax. Supply chain example – Fig. 5. 1

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

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

Wf. MS adapter message broker Smart. Quotation adapter database adapter Smart. Forecasting adapter Smart. Quotation DBMS applications Smart. Forecasting Copyright Springer Verlag Berlin Heidelberg 2004 e-mail adapter XYZ

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

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.

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

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

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

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

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

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 2 PC 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

B 2 B 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.

B 2 B 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 2 PC 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. •

B 2 B 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 B 2 B 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. • •

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

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

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

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 B 2 B 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.

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

Different Layers • Common base language – 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 (BPEL 4 WS).

Different Layers • Properties and semantics – 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.

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.

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.

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

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.

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.

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. , 2 PC) 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.

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. BPEL 4 WS seems to be emerging as the leading service composition language.

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.

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

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.

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

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

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 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.

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

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.

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