Download presentation
Presentation is loading. Please wait.
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
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.