WEB SERVICES ARCHITECURE

The core standards for Web services are:

(a) Creating a format for messages to be parsed from one business to another (XML document);

(b) Service description (WSDL);

(c) Transporting the document (SOAP);

(d) Providing databases to store the information (UDDI);

Although SOAP, WSDL, and UDDI provide a basic infrastructure, for Web services to run effectively, additional technologies are needed to complete the Web services architecture. Like the building of a house requires brick and mortar, a lot more is added and needed to complete the house and turn it into a home. Web services need security, process flow, transactions and guaranteed messaging to represent a complete

computing environment.

Security - Includes confidentiality, integrity, authentication, and authorization;

Process flow - Provides a flow of execution across a series of Web services;

Transactions - Needed for coordinating the results of multiple Web services;

Messaging - Entails configuring message paths and routing messages reliably across multiple network hops, including intermediaries;

The next section will discuss these important issues.

3.6.1 Security

To have a service that is efficient, more than the basics are necessary. Security is the first major area of importance when it comes to completing the Web services

The basic security issues include data confidentiality and integrity (ensuring that nobody steals your credit card number, or nobody changes the contents of your messages that you send/receive) and authentication/authorization (access rights for individuals/groups to resources). To ensure the confidentiality and integrity of the data in terms of securely sending/receiving the data, you need to make use of Secure Sockets Layer (SSL), which is implemented as HTTP over SSL (HTTPS). HTTPS is a technology which allows Web browsers and Web servers to communicate over a secured connection. This means that the data being sent is encrypted by one side, transmitted, and decrypted by the other side before processing. This is a two-way process, meaning that both the server and the browser encrypt all traffic before sending out data. Another critical and fundamental aspect of Internet security is the use of firewalls. Web services can be configured to inspect messages.

XML-based security standards are still evolving but it is safe to say that the authentication/authorization standard seems to be Security Assertions Markup Language (SAML).

The most common form of secure messaging for Web services will be to make use of SOAP over HTTPS with basic HTTP authentication. Because Web services will be exposing programs and stored data more, security is needed. Companies will be communicating with many services. Web services will therefore need an end-to-end security model because sensitive information will be passed from one service to another. Because there are many people communicating between each other, authentication is requested over and over again. One way of providing a reusable assertion with a trusted entity is by making use of SAML.

3.6.1.1 Standard Authentication Markup Language (SAML)

SAML provides a standard way to profile information in XML documents and to define user identification and authorization information (5). SAML implementations provide an interoperable XML-based security solution, whereby user information and corresponding authorization information can be exchanged by collaborating services (5). In terms of authentication and authorization information, SAML defines standard XML formats. These formats can be used from one person to the next in a call chain, using any transport technology. SAML provides single sign-on and end-to-end security for Web services. SAML will be discussed in more detail in chapter 6, section 6.6.2, page 87.

3.6.2 Process Flow

The second major area of importance when it comes to completing the Web services architecture is that of process flow. Process flow refers to the execution flow across a series of services. As people start to interact with one another via Web services, formal processes and procedures will need to be established for handling access to information technology systems just as businesses do internally.

Once there is program-to-program communication using Web services, the next step is to implement formal trading partner agreements and collaborations as process flows. There are two proposals for defining this sequence of messages into a business process framework (5). The first one being XLANG from Microsoft and the other one being Web Services Flow Language (WSFL) from IBM.

An example of a process flow would be one of automating a business transaction, such as filling in a purchase order or processing an insurance claim. This sequence of tasks can be invoked by making use of Web services, JavaBeans, CORBA objects, .NET and ERP Adapters, amongst others.

3.6.3 Transaction Coordination

Once the security has been put in place and the flow of the tasks has been established, the third step is to coordinate transactions. When multiple Web services are put into relationship, for example, in an automated business flow, results of these operations may need to be coordinated to ensure that the desired outcome was achieved. For example, if a hotel, flight and car rental reservation is to be made successfully, there needs to be proper coordination of transactions.

The protocol in place today that will ensure that transactions are coordinated properly is called the two-phase commit protocol. This protocol is based on the concept of either all operations on the data will succeed or all will fail as a unit. This software-based

transaction coordination ensures accurate recording for business operations involving multiple operations on data, despite hardware or software failures. In terms of Web services, this type of protocol is unsuitable due to the fact that the two-phase commit depends on the existence of a connection-oriented means of transport. Until a reliable session-oriented transport has been defined in the place of HTTP, this will remain a problem.

Various proposals have been considered to address this problem. One of the HTTPR or Reliable HTTP is an IBM proposal that layers a conver- sational protocol on HTTP request / res-

or BEEP when transaction coordination is required and then to use a form of traditional two-phase commit, such as Transaction Internet Protocol (TIP). Another alternative is to create an alternative protocol instead of the traditional two-phase commit protocol. The next section will introduce this alternative protocol, namely Business Transaction Protocol or BTP (19).

3.6.3.1 Business Transaction Protocol (BTP)

BTP is an alternative protocol that defines an XML protocol for placing long-running business-to-business (B2B) and other similar transactions into a sequence or process flow.

BTP has been designed solely to manage the results of transactions, be they successful or not. The results are then sent to the various files, database systems, queues, etc. Whereas the two-phase commit protocol will handle the entire process, from

coordinating actions to coordinating recovery after failure, BTP only provides facilities so that a shared agreement to the business transaction is reached.

BTP evolved due to the fact that the Web has transactions that are not connection- oriented (5). Traditional protocols like the two-phase commit are used in a connection- oriented environment. In the disconnected world of the Internet this type of technology is not suitable. This is a protocol that has not clearly emerged as yet.

3.6.4 Messaging

Once the security has been put in place, the flow of the tasks has been established and transactions have been coordinated, the fourth step is to define reliable routes for data to move and this is achieved in the form of messaging.

Figure 3.9 illustrates an example of a SOAP message path where the SOAP message can be routed via multiple network hops, via an intermediary, to its destination. A mechanism is needed to ensure successful transmission of the message along the entire route, and to report failure or fault information reliably to the original sender.

Figure 3.9 – A SOAP Message Path Including Intermediaries

SOAP Message Path

Sender Intermediary 1 Intermediary 2 Receiver

Blocks Exten- sible Ex- change Protocol (BEEP) permits simulta- neous and indepen- dent ex- changes of mes- sages between peers that have estab- lished a connec- tion

3.6.4.1 WS-Inspection

The Web services inspection language (WS-Inspection) was created by IBM/Microsoft to retrieve Web services descriptions from a known address. When the sender knows the receiver’s address but wants to find out what services the receiver offers is when WS- Inspection is utilized. It is another form of the UDDI registry and often easier to locate Web services because WS-Inspection has a focused capability and it focuses on a single target server.

3.6.4.2 WS-Routing

WS-Routing defines a complete message path for routing SOAP messages across a multihop network environment. The message path is defined with the SOAP envelope. WS-Routing supports message interaction patterns for one-way, request/response, and peer-to-peer conversations.

3.6.5 Summary

In summary, although SOAP, WSDL and UDDI provide a basic structure for Web services, it is not enough. For Web services to survive in today’s Internet environment other tools are needed.

Security is of the utmost importance and is also a very complex issue. By providing authentication/authorization in the form of password checking, SAML, and making use of firewalls, and ensuring confidentiality/integrity in the form of HTTPS, the basic critical elements are taken care of.

Secondly, with the Web, many people interact with one another and it is important that data flows correctly between the individuals. By ensuring that business transactions are broken up into tasks and grouped into a process flow, for example, when filling in an insurance claim, will provide a transaction that will be processed correctly.

Thirdly, the coordination of these transactions in the Web environment is also vitally important. If one task within a process flow is sent in the wrong sequence, the desired outcome could be incorrect and it could cost the company millions. Coordinating transactions in the Web services environment seems to be in its infancy. There are however solutions, whether or not they are the right ones, only time will tell.

Lastly, it is important that the transaction or message is routed to its destination efficiently. Due to the nature of the Internet a message may require multi-hops until it

reaches its destination and mechanisms need to be in place to ensure the efficiency of message routing.