Web Services Architecture

views updated

Chapter 2
Web Services Architecture

2.1 WHY ARE WEB SERVICES NEEDED?
2.2 WHAT ARE WEB SERVICES?
2.3 MAIN TECHNICAL SPECIFICATIONS OF WEB SERVICES
2.4 SUPPORTING PLATFORM OF WEB SERVICES
2.5 WEB SERVICES: CHALLENGES AND TRENDS
REFERENCES

2.1 WHY ARE WEB SERVICES NEEDED?

Web Services provide the foundation of Active Services. This chapter will focus on the architecture of Web Service, so that one can get an overall view of Web Services.

With the development of the Internet and the improvement of e-Business in enterprises, various organizations and commercial entities have gradually started focusing on the Internet, and thus increasing numbers of Internet applications come forth. Currently, not only can people publish or share information through the Internet, they can also deploy or acquire miscellaneous online applications such as online shopping, online office, e-Business, online education, online games, IP phone. Consequently, new demands for the power of service arise.

Web Services based on XML appear as the best means for further information sharing and promoting and developing Internet applications. Taking advantage of the current opening and interconnecting principles of the Internet, Web Services aim at establishing a technical standard that is ubiquitous, platform independent, and language independent on the present heterogeneous platforms, so as to realize interconnection and interoperation between different hardware and software platforms.

This chapter will introduce related concept and the main features of Web Services, the architectures, technical standards, and supporting platform of Web Services.

2.2 WHAT ARE WEB SERVICES?

2.2.1 CONCEPT OF WEB SERVICES

Research on Web Services has become a hot issue in software engineering and distributed computing. But what Web Service is still need to be clarified. From the standpoint of technical development and commercial application, Web Services could be described as follows:

Web Services are a set of application programs. W3C, a worldwide standardization organization, defines Web Services as “software application programs identified by URL (Uniform Resource Locator), whose interface and binding can be defined, described and discovered by XML components. Web Services can directly interact with other software through Internet based protocols.” In developers' viewpoint, Web Services are no more than a set of programs existing in the Web server. This set of programs is encapsulated into a black box and provides an outward API called through the Web. When it is necessary, the clients can call such API by programming and the results are returned to the clients through the Web.
Web Services are a set of services. Gambhir et al. suggest that: “Web Services are modularized application logic in the condition of the Internet that can be issued, located, and called through standard network protocols and data format.” Or rather in a more professional way: “Web Services are a kind of self-contained, self-described, and modularized application that can be issued, located, and called via the Web to accomplish functions from simple request to complex commercial transactions.” Once it is installed, the user or other applications can identify it and call the services afforded by it.
Web Services are a service platform. Web Services here refers to the overall technical framework for establishing Web Services. Thus, Web Services stand for a unified service platform integrating deployment, discovery, transaction, security, and authentication. And it possesses a series of related technical standards, which, in turn, guarantee its integrity and superiority as a service platform.
Web Services will open a brand new business model. With regard to business application, any advanced technology cannot go without the catalysis of commercial use. Though different companies develop their Web Services for different purposes, they all adopt one business model—software as a service—and focus on the intelligence and individuality of service. It can be predicted that with the application of Web Services and its related technologies, the model of “software as a service” in the future digital life, described by Microsoft with the application of Web Services, would undoubtedly bring thorough revolutions and fresh experiences to human beings in their future life.

To sum it up, Web Services is a set of XML-based application programs on the Internet, through which the Internet can provide users with information published and shared across different platforms as well as other related services.

2.2.2 CHARACTERISTICS OF WEB SERVICES

According to the definitions given above, the characteristics of Web Services can be summarized as follows:

Strong autonomy. Web Services are a reusable software module. Compared with structure or objected-oriented model, Web Services are a typical “black-box model.” It can be reapplied without considering the details of implementation. Web Services provide only the precisely defined interface called “the pact” for the users.
Loose coupling. Traditional software design requires close connection between different modules. The complexity caused by this close connection requires the developers to have full knowledge and control of the elements at both ends. In contrast, Web Services are loosely coupled. It needs very simple coordination and allows free customization.
Coarse granularity. In contrast to objects and components, Web Services emphasize on functional granularity. Semantically, Web Services encapsulate the discrete functions. A single Web Service is a self-contained “minor program” accomplishing the single task. Some Web Services themselves are applications.
Openness. All public agreements of Web Services are described, transmitted, and exchanged by open standard protocols. First, the external functions provided by Web Services are described in standard description language (e.g., WSDL). Second, the service interface described in standard description language can be identified.
Integration. The openness of Web Services leads to another character: integration. Because Web Services use simple and comprehensible Web protocols as the component interface description and cooperative description standards, they overcome the heterogeneity between different software platforms. No matter what kind of platform it is, CORBA, DCOM, or EJB, all can interoperate through such a standard protocol. Consequently, integration can be achieved under current conditions.

According to the definition and the characteristics of Web Services, it can be observed that unlike other distributed computing models (e.g., CORBA), Web Services computating model requires little as far as minimal architecture. Since Web Services employ universal network protocols and data formats (e.g., HTTP and XML), any system supporting these universal protocols would support Web Services. Meanwhile, the characteristics of strong autonomy, loose coupling, and coarse granularity allow Web Services to ignore the differences in programming languages and eliminate the competition of component standards. It, on the one hand, allows Web Services to have an abundant source, and, on the other hand, guarantees the feasibility on any platform regardless of its operating system, programming language, or object model.

2.2.3 ARCHITECTURE OF WEB SERVICES

Applied in an independent and modularized way, Web Services can be described, issued, identified, and called via the Internet. Accordingly, the architecture of Web Services is a conceptual framework, including three roles: service provider, service register, and service requester. The interactions between different roles are carried out through three operations: publishing, finding, and binding. These roles together with the operations jointly act on two Web Service entities: Web Services software module and its description. In typical situations, a service provider hosts a network-accessible software module (a realization of Web Service) through the network, define the Web Services description, and publish it to the service requester or service register. Then, the service requester may find in the local or in the service register for the service description, bind the service description to the service provider, and call the corresponding Web Services module for interaction. Figure 2.1 describes these roles, their related operations, and interactions.

As described in Figure 2.1, Web Services architecture includes two basic entities:

Service. Service is software computing on the Internet. The service providers publish software on the Internet, so the service requesters can obtain services by means of calling or interacting.
Service description. Service description consists of details about the service interface and implementation, including data type, operations, binding information, network location. Some service descriptions also include information about classification and other metadata, which usually help service requesters to find and use the services. Service providers can send service descriptions either directly to service requesters or to the service registration center.

Based on these two entities, Web Services architecture further defines three kinds of roles, three interactions that are employed by three roles according to Web Services and its description, as well as the developing cycle and the protocol stacks of Web Services as follows:

Roles. Roles in the Web Services architecture are as follows:
- Service provider. Service provider owns services and in the view of Web Services architecture, it is a software platform that includes service implementation.
- Service requestor. It is a commercial organization or an individual in need of certain functions. A service request can be conducted through the Web browser or, a client application program instead.
- Service registry. Here all services provided on the Web are registered, service description is stored by the service provider, service requester searches and finds the needed service and gets the binding information from the service of the provider. As for the static service binding, the service requestor can get service without choosing registration because the service provider can directly provide service for the service requester. For example, the services include local files, FTP sites, Web sites, advertisement, or Discovery of Web Services (DISCO).
Action.
- Publishing. The service provider first makes the service description according to prescribed standard and publishes it on the service register so that the service requester can find it. Publishing refers to the process of describing service and sending it to the server or service register. During the process of publishing, the service provider cannot deal with service description in the server until it passes identity verification.
- Finding. Finding is the process of service requester inquiring the service registry about the location of the service provided by the service provider. The service requester conducts searches in the following two cases: to search for available service interface description to simplify the program exploitation during the service design, and to search for the location and binding information of the required service during the service requirement. There are two modes in the operation of searching: browse pattern (i.e., browsing through general classification or searching by some key words, with a series of service sets as the result) and drill down pattern (i.e., direct access to the specific service description by way of a unique key word, with a single result).
- Binding. Binding is the descriptive information between a group of service providers and requesters, including service accessing path, calling parameter, returned results, transport protocol, and security requirements. Binding is to locate, connect, and access the service and start the interaction with the service according to the above accessing information, when a service requester sends his or her request.

Development life cycle of Web Services. The life cycle of Web Services development consists of four stages:

Building. It is the process of definition describing, developing, realizing, and testing Web Services. The building of Web Services can be completed through defining and modifying the current programs or by integrating other Web Services or application programs.
Deploying. It includes publishing the definition of the service interface and implementation, as well as the descriptive information to the service requester or service register, and deploying the executable program to the running environment (typically, a Web server).

Running. It is the stage of the calling and applying Web Services. The service requester operates through service finding and binding.

Figure 2.2 Protocol stacks of Web Services.
Network layer	HTTP, FTP, MQ, IIOP
Data representation layer	XML
Message transmission layer	SOAP
Service description layer	WSDL
Service publication layer	UDDI
Service discovery layer	UDDI

Managing. It refers to the monitoring and controlling of the security, accessibility, performance, service quality, operating process, and the implementation of the Web Services program.

Protocol stacks of Web Services. The protocol stacks of Web Services integrate the standards related to the implementation technique of Web Services into one framework. Such standards mainly consist of XML series made by W3C, SOAP, WSDL, and UDDI and also include some network protocols on data communication and data transmission. The functions of each layer are summarized in Figure 2.2.
- Network layer. The basis of protocol stack of Web Services is the network transmission layer, through which the service requester accesses the Web Services. The main protocols in this layer consist of HTTP, FTP, MQ, and IIOP, among which HTTP is becoming the standard network protocol in Web Services. However, in some extended applications, SMTP (for e-mail) and FTP (for file transmission) are also supported. Protocols like MQ are mainly adopted for transmission and interaction of middleware.
- Data representation layer. XML is the data representation protocol. It provides data and information describing methods for the entire Web Service. At present, it is the major standard for date representation and exchange. XML is the core and the foundation of an entire Web Service. XML is considered as the standard method of describing and exchanging information, regardless of Web Service call (the SOAP technology), Web Service interface description (the WSDL technology), or Web Service discovery (the UDDI technology). The data model is used to describe the construction of data (also called source data). It is also one kind of data that is used for XML language description.
- Message transmission layer. The message transmission layer is above the network transmission layer. It is responsible for the encoding and transmitting of the message description. SOAP is the primary protocol standard of this layer. It consists of four sections:
  - A mechanism of message content description using XML envelope.
  - A set of encoding rules for encoding different types of data.
  - A mechanism providing remote process call (RPC) and response.
  - A binding agreement on how to use transmission protocols of the sublayers.
- Service description layer. Service description provides a specific method to call the Web Services, with Web Service Description Language (WSDL) as the describing tool. WSDL is an XML-based language, which is used to describe service implementation and service interface. Note that we must describe the service interface before describing service implementation in WSDL.
- Service publication layer. This layer publishes the related services. In this layer, the service provider directly sends the WSDL document to the service requester. The action when the service provider issues WSDL documentation by e-mail is called direct issuing. Also, the service provider can issue the WSDL document to the registration base or center of the service requester. Such a registration base or center is described in UDDI, from which the service requester can get WSDL documents.
- Service discovery layer. Service finding relies on service publishing. Without published Web Services, no corresponding service can be found. The service requester gets the service description in a dynamic or a static state. For example, a service requester may find a service WSDL document as a local file through the finding layer. And this is a directly published WSDL document. This operation is called static finding. Also, this client may find this service WSDL document in a local WSDL registration base or public/private UDDI registration center while running. This is called dynamic finding.

2.2.4 CLASSIFICATION OF WEB SERVICES

According to the domains of the service requester, Web Services can be roughly divided into the following kinds:

Customer-oriented Web Services. These kinds of Web Services usually issue information to the users through the Web in a random (or user-oriented) way. Customer-oriented Web Services are mainly to send information to the users. In this mode of service, the system gets relatively less information from the users. Therefore, it can be considered as an asymmetric information flow. For example, the sending of the simple stock information to the mobile phone via a wireless network is a customer-oriented Web Service. Another example is sending a city map or a browsing service to a wireless PDA or a billboard.
Business-oriented Web Services. They represent electronic business processes, which are typically represented by current e-Businesses.
System-oriented Web Services. These kinds of Web Services aim at providing the service requester with the functions at the system level. It includes the monitoring of the system function and performance, authentication, security service, and the communication service between the service providers and communicators (e.g., Voice via IP and VOD). The main examples of system-oriented Web Services are the Internet service providers and the application service providers.
Device-oriented Web Services. Any network or service on the Internet needs various devices, which are either used for transportation and transmission or as the service receiving and applying terminal. Examples of these include the vending machine and the network printer on the Internet.
Domain-oriented Web Services. Different domains have different Web Services, such as education-oriented Web Services.

2.3 MAIN TECHNICAL SPECIFICATIONS OF WEB SERVICES

Section 2.2 illustrated the protocol stacks of Web Services. This section will further discuss the model and implementation mechanism of different Web Service protocols.

2.3.1 SOAP

SOAP is a standard protocol for Web Service exchanging based on XML. Jointly drafted by IBM, Microsoft, Develop Mentor, and other companies, SOAP was recommended by W3C as a distributed message processing protocol for heterogeneous platforms in 1999, and then became a fundamental protocol for Web Services interaction.

Conciseness and extensibility are two major designing objectives of SOAP. SOAP itself gives no definition of any application semantics, such as programming model or specific semantic implementation. Instead, it only defines a simple kind of mechanism, and represents application semantics by providing a modularized model and a mechanism for data encoding. In

addition, SOAP uses XML as data format, which allows data exchange between different systems and platforms, and thus provides a simple, smart mechanism for the Web Services to exchange structured and typed information with SOAP in a decentralized and distributed environment.

The SOAP specification basically consists of four parts: SOAP Envelop, Encoding Rules, RPC Representation, SOAP Binging.

SOAP Envelop defines an overall representative framework of a SOAP message. It can be used to show what the contents of a SOAP message are, who sent it, who should receive and deal with it, whether these operations are necessary or not, etc.

SOAP Encoding Rules are used to represent instances of the data types needed by application programs. It defines an encoding mechanism for interchanging data needed by applications or Web Services. They are also used to exchange instances derived from defined data types.

SOAP RPC defines an agreement to represent remote call and response. For example, how to bind HTTP or SMTP protocols to SOAP, how to transmit procedure call, by which part of concrete transmission protocol procedure responses should be transmitted and so on.

SOAP Binding defines an agreement on exchanging SOAP messages across networks using sublayer protocols. When being transmitted, SOAP messages can be bound with different protocols of various transportation layers, such as HTTP, SMTP, POP3. Since these protocols have spread all over various computer platforms and devices together with the Web platform, and get through the proxies and firewalls, SOAP allows communication between all applications or Web Services connected to the Internet by binding with protocols such as HTTP, SMTP, POP3.

In practical applications, SOAP is primarily used to call a Web Service. When it happens, the sender will transform parameter values of the called Web Services from local binary format into a XML document that represents the SOAP message, and then send this document to remote servers. And there are corresponding SOAP processors running on the remote servers, which will parse the XML document, extract parameter information of the method, restore them to binary format, and call the local Web Services.

2.3.2 WSDL

WSDL is a XML format language for describing Web Services. Jointly drafted by IBM, Microsoft, and other companies, WSDL was formally submitted to W3C in March 2001 and was approved afterwards.

While SOAP enables the interoperation between heterogeneous programs and platforms, WSDL provides the calling information needed in these interoperations. And it describes the related details involved in the interaction in the form of a document. The basic idea is to describe Web Services as a set of communication ports capable of information exchanging, and to send necessary parameters for calling a service and returned results from the services in the form of a message, so that all details involved in Web Services communication can be structurally described. Through WSDL, the caller can get information about data structure, message structure, transmission protocol, and other information needed for communication, and then call the corresponding services.

WSDL consists of six elements: Service, Port, Binding, Port Type, Message, and Types, which describe calling details of Web Services in layers as shown in Figure 2.3.

Types. It is data type definitions of message that is usually used to describe exchanged messages.
Message. It is the abstract definition representing the data to be transmitted. It defines a data structure for the entire message using data types defined by Types; that is, Message consists of one or more data definitions and their instances.
Port type. It is an integration of abstract operations. Each operation normally refers to one piece of input message and one piece of output message.
Binding. It associates the concrete protocols of the operations and messages with the data format specifications. That is, to let operations,input and output messages defined by port Type assign detailed concrete protocols and data format specifications.
Port. It is an address for binding from which a communication endpoint is defined. Through this port, Web Services can interact with other Web Services or applications.
Service. It is a definition of a Web Service that is used to aggregate a set of related ports.

Among the six elements, Types, Message, Port type, and Binding are interface definition parts of a Web Service. Separated from concrete network deployments or data format binding, they abstractly describe basic interface information of Web Services, so that the abstract definition of message and port types of Web Services can be made, and the reuse of these abstract definitions realized. Furthermore, Port and Service are implementation definitions of Web Services, which describe running information of a service. For example, the address of the called service and the protocols bound to the service, like HTTP, SOAP, etc.

2.3.3 UDDI

UDDI can be used for finding and publishing certain related Web Services. It was proposed by IBM, Microsoft, and other companies, and its latest version is UDDIv3.0.

UDDI provides a mechanism of searching and finding Web Services as a bridge between Web Service providers and users. Web Services are usable for a user after they have been equipped with SOAP and WSDL, but how to search and locate a Web Service on the Internet remains a problem. UDDI provides search function to users using a registry center with a large amount of Web Service description information, and, at the same time, allows Web Service providers to publish or modify certain service description information.

UDDI Registry Center is a general designation of the websites that provide public UDDI registry service. Logically, it is a uniform entity, but physically speaking, it employs a distributed architecture and a peer-to-peer network structure between different websites. So getting access to any of these sites means getting access to the UDDI Registry Center. Normally, the results from a UDDI operational entrance sites are the information of the entire area that the UDDI Registry Center is covering. Authentication is needless for searching a Web Service with a UDDI Registry Center. But authorization is mandatory for publishing Web Service information on a UDDI operational entrance site. At the same time, both the updating and removing

of information should be carried on the same operational entrance site, and authenticated with the original username of publisher.

The information model that Web Services use to register in UDDI Registry Center is the foundation of Web Services publishing and finding of UDDI protocol specifications. UDDI defines five core data structures:

BusinessEntity. It defines related description information about business entities provided by Web Services, and represents business organizations or entity structures that publish entity and service description information.
BusinessService. It is a substructure of BusinessEntity. It combines a series of descriptions of related Web Services, like Web Services belonging to the same business flow, or Web Services classified to the same type category.
BindingTemplate. It provides technical description that is necessary when calling a Web Service, and it includes URL addresses of remote Web Services, port information, and other information necessary for applications to communicate with remote Web Services.
tModel. It is a supplement to the above data structures. It represents a classification standard, a communication protocol, or the concrete format definitions of parameters needed for calling a service.
PublisherAssertion. It is newly added in UDDI2.0 and associates more than one registered BusinessEntity information elements with each other. These associated BusinessEntities may belong to the same entity.

These five data structures are the core of UDDI. With these five data structures UDDI gives the description of the Web Service, and all operations are carried out according to them. In fact, the process of users publishing service information is just the process of filling in related data structures, and the process of users finding a service is the process of acquiring data structures related to that service.

2.4 SUPPORTING PLATFORM OF WEB SERVICES

As a uniform industry standard, Web Services provide a technical standard to the users. Any individual or organization can integrate Web Services into his or her own supporting platform of Web Services according to the standard. These Web Service supporting platforms provide all around solutions and technical specifications for users on the design, integration, performance, security, or reliability of Web Services applications.

SUN J2EE and Microsoft.NET are two typical supporting platforms of Web Services; similar platforms include IBM Web Sphere, etc.

Microsoft.NET is a platform composed of server, client, and service. The framework of.NET consists of basic running library, user interface library, CLR, C#, C, VB.NET, Jscript.NET, ASP.NET, and every section of API in.NET frame. It can be divided into the following parts:

.NET platform including basic frame and tools for constructing.NET service and.NET device software.
.NET products and service including enterprise server (e.g., BizTalk Server 2002 and SQL Server 2000, which supports.NET framework) based on Microsoft.NET.
.NET service provided by the third party including mainly the application-level services developed on.NET platform by third-party software deverlopers.

J2EE is a set of standards, each of which prescribes how a certain type of function should be provided by Java. J2EE platform provides a comprehensive framework for the design, development, composing, and installment of Java application on a multilayer distributed application model. J2EE standard defines numerous APIs and many application-programming models for application development and system integration. The latest J2EE standard includes EJB 2.0, J2EE Connector Architecture 1.0, JDBC 2.0, JSP 1.2, Servlet 2.3, JTA 1.0.1, JMS 1.0.2, JNDI 1.2, Java RMI 1.0, RMI/IIOP 1.0, JAAS 1.0, JavaMail 1.1, JAXP 1.1, etc.

On the whole, J2EE supports Web Services by a group of API packs (JAXM, JAXP, JAXR, JAX-RPC). Web Services in J2EE are usually realized through EJB.

In.NET Web Services are directly constructed on the.NET platform, which provides related services. The framework of.NET includes a series of Web Services standards like SOAP, WSDL, and UDDI, etc, and the Web Services are usually realized with.NET Managed Component (including Managed Class and COM/COM+component).

2.5 WEB SERVICES: CHALLENGES AND TRENDS

2.5.1 TECHNICAL CHALLENGES IN WEB SERVICES

Although the standards and protocols of Web Services are already mature, and some practical applications have come forth, there are still many not- so-finished

aspects of Web Services that require further research and improvement. The main problems Web Services are facing can be roughly described as follows:

Reliability. When the host of a Web Service goes offline temporarily, it is necessary to have a mechanism to notify the users, help them find and use alternative services of other providers, or wait for the original service to be available.
Security. Some Web Services will be publicly available without protection, but most business-related applications will use encrypted communication with authentication. HTTP on SSL usually provides basic security, but some services need high security assurance. So far, the label and efforts of Web Services in security have nothing to deserve mention.
Transaction. A traditional transaction treatment system employs two-stage submission. All the resources involved are composed and locked before the transaction takes place and released after that. This strategy is efficient in a closed environment for a short transaction, but it does not work well when a transaction lasts over hours or days in an open environment.
Flexibility. Since the current component system, e.g., Enterprise Java Bead (EJB), can be used as Web Services, it is possible to make use of the existing load balance technology and other scalability mechanism.
Charge counting. When a user uses Web Services, the time he spends accessing and executing a Web Service needs to be counted and the charge needs to be summed up.
Management. As a highly distributed system, Web Services require a set of management mechanisms. Since the feature of the whole system is the function of features in the subsystems, the management system of each Web Service needs a particular method of coordination.

These problems require further research and solution.

2.5.2 TRENDS OF WEB SERVICES

After overcoming the technical challenges given above, Web Services will see new development and have wider application. Software entities chiefly dedicated to Web Services exist in every node of the Internet in an open and self-controlled manner, and interconnect and coordinate across the network with other software entities. This changes the Internet from an information publishing and sharing platform to a large-scale distribution–computing

platform. People acquire from the Internet not only various information but also diversified services. However, examined by the true user-oriented requirement, current techniques of Web Services and methods of Internet services have the following defects:

At the level of realization, current services are based on the fixed computing module and incapable of functioning extension.
At the level of operation, current services are based on the stationary deployment and incapable of sensing the change in user requierments. Hence, it cannot reach the level of user-oriented “service on demand.”

To completely solve this problem, the current process of Internet service implementation and operation must be changed. Users should be free to choose a suitable function set according to their needs. Active finding, customization, load, and utilizing should be introduced to support new service and new application mode. The current passive mode of service employment must be altered. Intelligence of the Internet service should be improved so that people can receive the on-demand and individual service from the Internet whenever and wherever. This new mode of application is called Active Service on the Internet. We will introduce the architecture and implementation of Active Services in the next chapter.

REFERENCES

Benatallah, B., Casati, F., and Toumani, F. (2004). Web service conversation modeling: a cornerstone for e-business automation. IEEE Internet Computing, 8(1), 46–54.

Clark, D. (2002). Next-generation web services. IEEE Internet Computing, 6(2), 12–14.

Curbera, F., and Duftler, M., et al. (2002). Unraveling the Web services web: an introduction to SOAP, WSDL and UDDI. IEEE Internet Computing, 6(2), 86–93.

Extensible Markup Language (XML) 1.0 (Third Edition). http://www.w3.org/TR/REC-xml/

Gaedke, M., Gellersen, H., et al. (1999). Object-oriented Web engineering for large-scale Web Services management. Proceedings of the 32nd Annual Hawaii International Conference on System Sciences, 1(5). IEEE Press.

Gambhir, S. Secret Services, from http://www.pcmag.com/article2/0,1759,93474,00.asp?o=5&p=2

Huhns, M. N. (2002). Agents as Web services. IEEE Internet Computing, 6(4), 93–95.

Huhns, M. N. (2003). The sentient Web. IEEE Internet Computing, 7(6), 82–84.

IBM Software Group. Web Services Conceptual Architecture, from http://www-3.ibm.com/software/solutions/webservices/pdf/WSCA.pdf

Lea, D., and Vinoski, S. (2003). Middleware for web services. IEEE Internet Computing, 7(1), 28–29.

Microsoft Corporation. Microsoft.net Information, from http://www.microsoft.com/net/

Ouzzani, M., and Bouguettaya, A. Efficient access to Web services. IEEE Internet Computing, 8(2), 34–44.

Patil, S., and Newcomer, E. (2003). ebXML and Web services. IEEE Internet Computing, 7(3), 74–82.

Pierce, M., and Fox, G. (2004). Making scientific applications as Web services. IEEE Computational Science and Engineering, 6(1), 93–96.

Preece, A., and Decker, S. (2002). Intelligent web services. IEEE Intelligent Systems, 17(1), 15–17.

Shohoud, Y. Introduction to WSDL, from http://www.devxpert.com/tutors/wsdl/wsdl.asp

Simple Object Access Protocol (SOAP), from http://www.w3.org/TR/soap/