Ajax Hacks

SOA WOA and SaaS

SOA components contain Web services, RPC layer services for applications, and generic services written in traditional applications. Most of the SOA components are written in Web services, as modeled in Figure 2.11.

figure 2.11 SOA higher-level view.

A Web Service can be defined in the following way:

A Web service is a software component developed to support interoperability over a network using an interface described in WSDL, a machine-understandable format. Other systems communicate with the Web service, using SOAP

messages that are typically transported using the HTTP protocol with XML

messaging.

How SOAP works was covered in the protocol section of this chapter. Web services can be invoked using SOAP methods from anywhere on the network over Transfer Control Protocol (TCP) ports 80 and 443 using the HTTP protocol.

Two other protocols, Universal Description, Discovery, and Integration (UDDI) and WSDL, are also used to determine Web services' locations and access methods.

UDDI is a Web-based distributed directory that enables business entities to register themselves on the Internet and look up other business entities. You can think of the UDDI as the Internet-equivalent of a traditional yellow pages telephone directory. An example should make things clearer. Assume there are several book stores, of which some want to launch Web services. What these book stores must do is to create the Web service and register at a common location. Another book store that doesn't have itself registered on the Internet but wants to access these Web services will have to simply visit this common place and search for the requisite information. UDDI can be seen as one large business registry for Web services. In the past IBM, HP, and Microsoft ran this repository, but now private repositories need to be placed on their own infrastructures. For example, Amazon running with several Web services can define one UDDI server where the location for each of its Web services is posted. The server can be queried to determine various locations. Once the location is available, the client can start accessing these services.

WSDL is an XML document that serves two purposes: it defines how to access Web services and it furnishes information about where to access these Web services. WSDL specifies the location and operations of Web services. Any Web services client interested in consuming Web services can fetch critical information from WSDL and build specific requests.

Its XML document contains various nodes such as types, message, portType, and binding. These nodes contain information about methods supported by Web services, data types, and access points. Based on this information, a request can be built to access Web services.

For example, here is a simple .NET Web service sample code for an "echo" service. A .NET Web service's resource ends with an ASMX extension:

<%@ WebService Language="c#" Class="echo" %>

using System;

using System.Web.Services;

public class echo

[WebMethod]

public string echome(string text) {

return text;

The preceding file name is echo.asmx. Assume that this resource resides at the location http://soa.example.com/. This resource's WSDL file can be accessed at the following URL by adding "?WSDL" to the resource:

http://soa.example.com/echo.asmrfwsdl

Figure 2.12 shows the resulting XML document with different nodes from which actual SOAP requests can be built. The Web service's proxy can parse this WSDL file and generate proxy code for the Web service.

<wsdl: definitions targetNamesi:iace="htip://tempun.org/">

+ <s schema elemeitfFormDefault=''qualified" targetNamespace—'htlp/Zte </wsdl:types>

+ <wsdl: message name-'e chôme Soap In" ><Avsdl message^ + <ws(U message name—'e chôme Soap Out" ></ws <11 message>

- <wïiII port Type iiame="echoSoap"> - <wsdl dpera tion name— schôme " >

<wsdl input message="tns:echomeSoapIn"/^ <ws <11 output me s s a ge—'tas : e chôme S o ap Out1 V> </ws<lL operatiofi'? </ws <11 : n ûltTyp e >

+ <ws<U.bm<lnig name—1 echo Soap" typ e="tns : e cho S o ap " > </ws ill binding-+ <ws<lTbm<liug name="echoSoapl2" type—'tns:echo Soap"></ws<11 bm<lmg> + <ws (Il s erviee iiaine="echo"></wsdl serviced </ws ill definitions >

figure 2.12 WSDL file for an echo Web service.

The following SOAP request can invoke this Web service: POST /echo.asmx HTTP/1.0

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services

Client Protocol 1.1.4322.2300) Content-Type: text/xml; charset=utf-8 SOAPAction: "http://tempuri.org/echome" Content-Length: 305 Expect: 100-continue Connection: Keep-Alive Host: soa.example.com

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body>

<echome xmlns="http://tempuri.org/">

<text>Hello Web 2.0!!</text> </echome> </soap:Body> </soap:Envelope>

The following response is obtained for this echo method.

HTTP/1.1 200 OK Connection: close

Date: Thu, 08 Mar 2007 12:36:19 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Cache-Control: private, max-age=0 Content-Type: text/xml; charset=utf-8 Content-Length: 351

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body>

<echomeResponse xmlns="http://tempuri.org/">

<echomeResult>Hello Web 2.0!!</echomeResult> </echomeResponse> </soap:Body> </soap:Envelope>

In this manner any Web service running on an SOA framework can be accessed. SOA can be called from any infrastructure and is potentially language independent at both the server and client ends.

As shown in Figure 2.7, SOA can use XML-RPC as well. On the server side SOA components are created using XML-RPC. Various technologies support XML-RPC development, such as PHP (Hypertext Preprocessor) Java Server Pages (JSP) and .NET. This component acts as a server-side XML-RPC service and can be called using XML.

Several Web 2.0 applications run with traditional Web application resources such as JSP, PHP, and ASP, but they are designed as XML services. This application publishes OpenAPI on a popular portal's Web site like Yahoo and Google, and it allows integration with other applications using typical XML calls. Often, these services use private customized APIs that are not published but are circulated to closed groups that include partners and customers only. These APIs are also part of the SOA infrastructure. This is how SOA can be built in many different ways, and each application uses one or the other depending on their needs.

WOA is just an offshoot of SOA, but it is redefined based on the underlying protocol or architecture style. We have covered REST in the protocol section. An application running on REST and working in a distributed fashion is considered as WOA. REST is considered as WOA because it uses Web URLs as endpoints and can be scaled easily. On a higher level there is marginal difference between SOA and WOA.

SaaS is another way of hosting services-oriented architecture. SaaS has two types of services: application hosting and software on demand. Enterprises are moving their applications and software to the Internet in next-generation applications. Efficient bandwidth is making this model possible, where client applications are becoming thinner and server components serve as a thick layer. Numerous applications such as Microsoft Office are moving to the SaaS framework and can be accessed from anywhere using a thin browser. This architecture is seeing a lot of innovations. Web 2.0 applications now come bundled with the operating system running in the Web browser as a virtual Web operating system. These Web operating systems use JavaScript, objects, and Flash modules. SaaS is another representation of Web 2.0 applications and can be considered as a server-side component as illustrated in Figure 2.7.

0 0