6.5 Solution Stack

6.5.1 Introduction

While the full architecture is a work in progress, we explain what the building blocks are that need to work together. Delegating work, which is one key focus, depends on the "system" understanding the kinds of goals people have and how these can be performed by plans or processes that achieve those goals. Much of everyday life will be characterizable in this way. Individuals will have tailored user profiles that describe how they vary from standardized approaches with nominal defaults. This will require efforts to standardize the semantics of processes and how they can be achieved.

With Web services, information sources become components that you can (re)use and mix to enhance networking applications ranging from a simple currency converter, stock quotes, or dictionary to an integrated, portal-based travel planner, procurement workflow system, or consolidated purchasing system with processes across multiple sites.

For these reasons, the architecture of a "Web services stack" varies from domain to domain. The number and complexity of layers for the stack depend on the service it provides. Each stack requires Web services interfaces to get a Web services client to speak to an application server, or middleware component, such as CORBA, Java 2 Enterprise Edition (J2EE), or .NET. To enable the interface, SOAP is often used, as well as SOAP with Attachments (SwA), and Java RMI, among other Internet protocols.

Thus, starting with XML and Web standards, we will have to fill out the semantics of tasks , people, goals, resources, etc., so that devices from various manufacturers can work with services provided by various service providers to get work done. HP's e-speak concepts laid out much of this. UDDI and Web services are putting down the foundations for service-centric computing, service discovery, and service invocation. Much of the user interface experience will be all that users notice or care about, but behind the covers everything will have been rearranged to make possible delegation of work to agents .

Although XML has achieved universal acceptance as a standard format for exchanging data between disparate systems, developers still lack an equally accepted protocol for secure process-to-process communication. Several standards bodies, including the IETF [43] , the W3C, OASIS and the UN/CEFACT, are addressing this challenge. Their goal has been to develop a set of specifications to allow any business of any size in any industry to do business with any other entity in any other industry anywhere in the world.

[43] http://www.ietf.com/

Agents will need to communicate with one another and be able to monitor, control, and report on their results. Users will want to reinforce the "system" for doing the right things and, perhaps punish it or criticize it for doing undesired things. Adaptive learning processes will need to convert this feedback into improved performance. Network economics should be exploited to get multiplicative effects from allowing all the knowledge-based elements to interact with others, so that when new areas of task competency are developed, they can immediately augment and combine with the other areas of competency a user already exploits.

Every single capability required for the future depicted thus far exists today somewhere in the IT labs of the world, and most of the capabilities have been at an adequate level for practical deployment for at least five years . The challenges can be divided into three different levels:

  1. Component capabilities such as speech understanding or text to speech.

  2. Agent architecture including task knowledge.

  3. Service economy including especially Web services.

The current capabilities and remaining challenges in each of these areas are described elsewhere in this book. 1 is discussed in Chapter 3, 2 in Chapter 7, and 3 at the beginning of Chapter 6.

To describe services, information, and processes in a software- and hardware-independent way, it is necessary to introduce a data exchange standard that is capable of being on all platforms and within all solutions. It has become quite clear that this standard will be XML, which was introduced a few years ago and has become the de facto standard for the exchange of information.

Although there are a variety of Web services architectures, XML can be considered a universal client/server architecture that allows disparate systems to communicate with each other without using proprietary client libraries. This architecture simplifies the development process typically associated with client/server applications by effectively eliminating code dependencies between client and server, and the interface information is disclosed to the client via a configuration file encoded in a standard format (e.g., WSDL). Doing so allows the server to publish a single file for all target client platforms.

Figure 6.1 gives you an overview on the solution stack that will be discussed in the next section in more detail.

Figure 6.1. Solution stack

graphics/06fig01.gif

6.5.2 Service Negotiation

If we look at the solution stack (Figure 6.1), we can see that Service Negotiation is the top layer. On this layer, the two parties involved in a certain transaction can negotiate and agree on the protocols that should be used to aggregate Web services. This layer is also referred to as the Process Definition layer, covering document, workflow, transactions, and process flow (see also Figure 6.2). The protocols that are negotiated are not only about the data formats and how they are transmitted (e.g., XML and Corba), but typically also the security parameters and quality of service parameters are negotiated in this step (e.g., only encrypted traffic and 256 kbps minimum throughput).

Figure 6.2. Service Negotiation Diagram

graphics/06fig02.gif

It is important to note that the service negotiation layer should not require a manual intervention, but should work autonomously and hidden from the user. It should support rapidly changing user requirements, for example, if a user wants to start a video session or an application requires a database update. It should also be possible to support changing network capabilities; a network should be able to tell the user of costs on a new link, for example. And it should support network-to-network negotiation.

6.5.3 Workflow, Discovery, Registries

The WDR (Workflow, Discovery, and Registries) layer is used to create workflows using Web Services Flow Language (WSFL) and Microsoft XLANG, which are XML languages to describe workflow processes and spawn them.

WSFL specifies the interfaces of Web services. It determines whether the Web services should be treated as an activity in one workflow or as a series of activities. While WSFL complements WSDL, XLANG is an extension of WSDL. WSFL supports the flow and global models. The flow model describes business processes that a collection of Web services needs to achieve. The global model describes how Web services interact with one another. XLANG, on the other hand, allows orchestration of Web services into business processes and composite Web services. WSFL provides a better model presentation, while XLANG is better with the long-running interaction of Web services. Web services can be declared as private to avoid the exposure of details to public applications.

Web services that can be exposed may, for example, get information on credit validation activities from a public directory or registry, such as UDDI. There are many directories that can be used in conjunction with Web services for business-to-business (B2B) transactions in a complex Enterprise Application Integration (EAI) infrastructure under certain conditions. ebXML, E-Services Village, BizTalk.org, and XML.org are probably the best-known directory services. Web services is still primarily an interfacing architecture, and it needs an integration platform to which to connect. The integration platform covers the integration an existing applications that cannot work as Web services yet.

Hewlett-Packard, IBM, Microsoft, and SAP launched implementation of their UDDI sites that conformed to the latest specification, including enhanced support for deploying public and private Web service registries and the interface (SOAP/HTTP API) that the client could use to interact with the registry server. In addition to the public UDDI Business Registry sites, enterprises can also deploy private registries on their intranets to manage internal Web services using the UDDI specification. Access to internal Web service information may also be extended to a private network of business partners .

6.5.4 Service Description Language

The Web service description language (WSDL) is required to connect to a Web service. The WSDL is used to describe the communications in some structured way, based on standardized communications protocols and message formats. It addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL provides documentation for distributed systems and serves as a recipe for automating the details involved in applications communication.

With it, service requesters can search for and find the information on services via UDDI, which, in turn , returns the WSDL reference that can be used to bind to the service.

To simplify the description of the structure of data in a common format, the Web Service Conversational Language (WSCL) can help developers. The structured data is described in XML Schema, which can be recognized by customers, Web browsers, or indeed any XMLenabled software programs.

6.5.5 Messaging

The Messaging layer provides standardized technologies that act as the envelope for XML-based messages, covering message packaging, routing, guaranteed delivery, and security. Most commonly used is SOAP. Messages are exchanged based on the status of various Web services as the work progresses.

SOAP describes the data items exchanged at a high level; that is, it treats them as documents. These documents may or may not contain descriptions of their content, but they all share one common property: they are structured. Structure is given to these documents by describing them in XML format. SOAP itself is described as a sequence of XML tags, thus telling what the content of a SOAP message is. SOAP can be used to make remote procedure calls. In this way, the Body element of the SOAP message contains a tag that represents the name of the function that is to be called at the receiver side. The receiver will append the text Reply to the tag's name and return it to the sender.

6.5.6 Transport Protocols

The transport protocols layer provides mechanisms and technologies to connect systems and communicate data between these systems. These protocols include the standards ones, like Hypertext Transfer Protocol (HTTP), Secure HTTP (HTTPS), File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP), new transport protocols are about to be established: DIME, HTTPR, and BEEP. DIME (Direct Internet Message Encapsulation) is a lightweight, binary message format designed to encapsulate one or more application-defined payloads into a single message construct. HTTPR is a protocol that offers the reliable delivery of HTTP packets between the server and client. BEEP is a generic application protocol kernel for connection-oriented, asynchronous interactions.



Radical Simplicity. Transforming Computers Into Me-centric Appliances
Radical Simplicity: Transforming Computers Into Me-centric Appliances (Hewlett-Packard Press Strategic Books)
ISBN: 0131002910
EAN: 2147483647
Year: 2002
Pages: 88

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net