Web services constitute a special class of services. The services from this class are highly interoperable.

Figure 3.2 shows a conceptual view of a Web service. The high level of interoperability in this case is achieved through uniform discovery and description standards provided by the framework. Note that the interoperability here is limited among the services that abide by the same set of standards. Web services inherit several characteristics of component-based architectures. Chief among them are:

Figure 3.2. A Web service.

However, a Web service is not the same as a component. Several characteristics differentiate the two.

The underlying communication mechanism in the Web services paradigm is Simple Object Access Protocol (SOAP). SOAP is an Extensible Markup Language (XML) over Hypertext Transfer Protocol (HTTP)-based protocol for accessing components (for example, services and objects) in a platform-independent manner. Appendix G provides more details about SOAP technology.

The major advantage of this lightweight protocol is that it allows services running in one kind of platform (Java 2 Enterprise Edition [J2EE]) to communicate with services in the same or another kind of platform (.NET). Since HTTP is available on all popular platforms, it provides an already at-hand solution to the problem of how services running on different platforms in a network can communicate with each other. The SOAP specification specifies exactly how to encode an HTTP header and an XML file so that a service on one platform can interact with a service in another. Another major advantage of SOAP is that because it is XML/HTTP-based, it can go through the firewall in the same manner that HTTP requests do. Therefore, SOAP solves two obstacles in the service paradigm — interoperability and firewall traversal.

The Service Description layer of the stack refers to the ability of a service to communicate what a Web service can do, where it resides, and how to invoke it. The Web Services Description Language (WSDL) supports service description capabilities in the Web services paradigm. WSDL is an XML-based grammar used to describe services a business offers; it also provides a way for individuals and other businesses to access those services electronically. A WSDL describes four critical pieces of data:

Appendix H explains WSDL in further detail. WSDL, like SOAP, is also platformand language-independent and is used primarily to describe SOAP-based Web services. WSDL is derived from SOAP and IBM’s Network Accessible Service Specification Language (NASSL). WSDL replaces both NASSL and SOAP as the means of expressing business services in the UDDI registry.

Axis is an open-source product from Apache Software Foundation — an open-source community responsible for developing several notable products such as Tomcat and Cocoon. Axis can be considered as the SOAP engine that can facilitate both Web service deployment and consumption.

Axis can act as a stand-alone server. Axis is also pluggable with Tomcat — a feature that can be used for more complex architectures. In addition to the server capabilities, Axis provides a few tools that can be used to ease the development effort for server-side and client-side developers. The Java2WSDL tool can used to create Web service specific components for a Java class representing certain functionality. On the other hand, the WSDL2Java utility can be used to generate client-side proxies for the Web service.

Microsoft .NET is a development and deployment platform geared towards Web services. It contains several software technologies that individually address a specific feature necessary for Web service development. As such, several of these software components are upgrades of existing products such as SQL server and BizTalk server. However, under the .NET aegis, these components have a common framework to support Web services. This framework, understandably called .NET Framework, provides the backbone for the Microsoft technologies and products that support Web services. Figure 3.4 depicts that .NET technology stack.

Figure 3.4. .NET technology stack.

Web services allow a decoupling of the business logic from the deployment. Hence, the first step in developing a Web service is to identify (or create) the business logic which will be exposed via the Web service interface. In our Emp401kService example, the business logic is very straightforward as can be seen from the business logic files Emp401kService.java and Emp401kServiceDOTNET.asmx.cs. Figure 3.5 depicts the service architecture.

Figure 3.5. Emp401k Architecture.

The getFundList method retrieves the list of the selected mutual funds available in this 401(k) plan from a backend database. The getEmployeeContribution method takes an employee number and returns the mutual funds and associated contribution percentages. Appendix F provides the schema for the 401(k) contribution database. Notice that there is nothing Web service-specific in the business logic code for the most part.

The way our service is architected, it takes character strings as input and returns a string in each case as output, but it could very well have used XML for information sharing. Later, in Section 3.5, we discuss the document exchange paradigm in greater detail.

Once the business logic or service logic is completed, the next step is to deploy it as a Web service. Before we discuss the deployment of the Emp401kService, let’s recap what the Web services interaction paradigm will look like after deployment.

Notice that in both the .NET and J2EE worlds, the service takes programmatic SOAP-based requests and returns SOAP-based responses. Also, notice that the J2EE service is deployed with the Apache Axis server or J2EE container whereas the .NET service is deployed on Microsoft’s Internet Information Server (IIS). The .NET paradigm is very integrated with Visual Studio .NET. The point and click nature of Microsoft tools masks many of the steps that occur between business logic creation and service deployment. We focus on the J2EE environment and return to .NET towards the end of this section.

Deploying Web services in Axis is supported by a set of utilities that are bundled along with the Apache Axis Web service tools. After developing the business logic, the following steps are required for deploying the business logic as a Web service.

C:> java org.apache.axis.wsdl.Java2WSDL -o Emp401kService.wsdl 
      -l"http://localhost:8080/axis/services/Emp401kService" 
      -n "urn:Emp401kService" Emp401kService 

<wsdl:message name="getFundListRequest"> 
</wsdl:message> 
<wsdl:message name="getFundListResponse"> 
      <wsdl:part name="return" type="SOAP-ENC:string"/> 
 </wsdl:message> 
<wsdl:message name="getEmployeeContributionRequest"> 
      <wsdl:part name="in0" type="SOAP-ENC:string"/> 
</wsdl:message> 
<wsdl:message name="getEmployeeContributionResponse"> 
    <wsdl:part name="return" type="SOAP-ENC:string"/> 
</wsdl:message> 
... 

<wsdl:portType name="Emp401kService"> 
  <wsdl:operation name="getEmployeeContribution" 
     parameterOrder="in0"> 
    <wsdl:input message="intf:getEmployeeContributionRequest" /> 
    <wsdl:output message= 
       "intf:getEmployeeContributionResponse" /> 
  </wsdl:operation> 
  <wsdl:operation name="getFundList"> 
    <wsdl:input message="intf:getFundListRequest" /> 
    <wsdl:output message="intf:getFundListResponse" /> 
    <wsdl:fault message="intf:Exception" name="Exception" /> 
    <wsdl:fault message="intf:ClassNotFoundException" 
       name="ClassNotFoundException" /> 
  </wsdl:operation> 
</wsdl:portType> 
... 

... 
<wsdl:service name="Emp401kServiceService"> 
  <wsdl:port binding="intf:Emp401kServiceSoapBinding" 
     name="Emp401kService"> 
  <wsdlsoap:address location= 
     "http://localhost:8080/axis/services/Emp401kService" /> 
  </wsdl:port> 
</wsdl:service> 
... 

C:> java org.apache.axis.wsdl.WSDL2Java -s 
 -Nhttp://localhost:8080/axis/services/Emp401kService 
   =Emp401kService 
 -Nhttp://DefaultNamespace=Emp401kService Emp401kService.wsdl 

Deploying Emp401kService

Before the service is ready to be deployed, all necessary business logic classes need to be made available to the Axis SOAP server. To accomplish this, make all the Web service classes available in the class path.

At this point, the environment is set to deploy and run the service, Emp401kService(). Start the Axis server with following command:

C:> java org.apache.axis.transport.http.SimpleAxisServer 
-p 8080 

To deploy the Web service, the Axis Admin client tool is used. This tool uses the file deploy.wsdd. Sample contents of this file is shown below:

Example . deploy.wsdd

<deployment> 
  <!-- Services from Emp401kServiceService WSDL service --> 
  <service name="Emp401kService" provider="java:RPC"> 
      <parameter name="className" 
   value="Emp401kService.Emp401KServiceSoapBindingSkeleton"/> 
      <parameter name="allowedMethods" value="*"/> 
      <parameter name="scope" value="Session"/> 
  </service> 
</deployment> 

C:> java org.apache.axis.client.AdminClient deploy.wsdd 

The simplest way to ensure that the service is deployed appropriately (from a client perspective) is to enter the URL for the WSDL in the browser — http://localhost:8080/axis/services/Emp401kService?wsdl. The WSDL file for the Emp401kService() is depicted in Figure 3.6.

Figure 3.6. Emp401kService WSDL.

The client logic should be part of the same service proxy package as follows:

package Emp401kService; 

Invoking the exposed Web service methods involves exchanging the SOAP messages described in the WSDL file. The method, Emp401kServiceServiceLocator(), provides the instance to the class that facilitates this communication. Individual methods from this class, Emp401Service(), correspond to methods of the original service. Therefore, the following code segment invokes the getFundList() method of the Emp401kService().

binding = new Emp401kService. 
            Emp401KServiceServiceLocator().getEmp401KService(); 
... 
String fundList = binding.getFundList(); 

To observe the example code in action, start the Axis SOAP server. We assume that the service has been deployed and the installation is verified. Open a command window and, from the appropriate directory, start the client program as follows:

C:> java Emp401kService.Emp401kClient 

The menu will appear as shown in Figure 3.7. To view the list of funds available, choose option 1. Contributions for a specific employee can be found through option 2. The list will appear as shown in Figure 3.8.

Figure 3.7. Starting Emp401kClient.

Figure 3.8. Result of invoking getFundList() from Emp401kClient.

Web services development in .NET can be completely contained within the Visual Studio .NET development tool. While developers on the Microsoft platform can manually create their .NET Web services without the help of the integrated development environment (IDE), our discussion is based on creating the Emp401k service with the help of the IDE.

First off, either the Internet Information Server (IIS) or the Personal Web Manager (PWM) is needed to run the Web services. The J2EE platform is application server-based and Web services run in the application server. However, in the .NET paradigm, Web services run in the Web server as an extension to the Active Server Pages (ASP) technology. Start the Web server as it is required when developing and building .NET Web services.

Once installed, start Visual Studio .NET from the Start menu. Start a new project from the File menu. On the right-hand side, choose the programming language; for this example we use C#. However, ensure that the ASP .NET Web service template is selected and that the name of the Web service is provided in the Location box at the bottom of the dialog box. We have named this one: Emp401kDOTNET(). Figure 3.9 depicts this step.

Figure 3.9. Start a new Web service project in Visual Studio .NET.

As the IDE processes this new Web service, a familiar graphic as seen in Figure 3.10.

Figure 3.10. Creating the new Web service in Visual Studio .NET.

The result of this process is that (assuming that PWM or IIS is installed with its default configuration) a new directory with the name of the Web service is created in C:Inetpubwwwroot. In this case, recall that it is Emp401kDOTNET. Check to make sure that this directory is created and also change the Web sharing properties on this directory. Right click on the directory name and go to the Web Sharing tab. Select Share this Folder check box. A property dialog box will immediately pop up and the following should be selected:

Figure 3.11 depicts this step.

Figure 3.11. Setting Web sharing properties on your Web service directory.

At this point, we are ready to modify the .NET Web service template to create the Emp401kDOTNET() Web service. Select the Service1.asmx in the Solution Explorer and rename it to the service name — in this case, Emp401kDOTNET.asmx. Also right click this file and set it as the start page for the service. Modify the template to add the required business logic. Emp401kDOTNET.asmx is the main Web service business logic file of the Web service.

Recall from the J2EE example that we use a database backend for this Web service. In the .NET paradigm, this requires having ODBC .NET Manager installed in the environment. Download and install this from Microsoft Developer Network (MSDN) Web site. We provide a shortcut to this URL on the accompanying CD. Once this is installed, include the database access libraries: Microsoft.Data.Odbc and System.Text in the asmx file. In addition, add reference to the ODBC library from the Project → Add Reference → Microsoft.Data.ODBC.dll.

Develop the business logic, similar to that in the J2EE paradigm, for getFundList() and getEmployeeContribution() methods.

Take a look at the code for the getFundList() method:

[WebMethod] 
public string getFundList() 
{ 
DataSet dataset= new DataSet(); 
OdbcDataAdapter adapter = new OdbcDataAdapter(); 
adapter.SelectCommand = new 
         OdbcCommand("SELECT FundName FROM FundTable", myconn); 
adapter.Fill(dataset); 
StringBuilder resultString = new StringBuilder(); 
//iterate through the resultant dataset and build result string 
for(int i=0; i<dataset.Tables["Table"].Rows.Count; i++) 
{ 
 resultString.Append(dataset.Tables["Table"]. 
                                        Rows[i]["FundName"]); 
       resultString.Append("|"); 
} 
//Return the result in String format 
return resultString.ToString(); 
} 

The code looks fairly straightforward. There is generated code and template code that takes care of the Web services aspects of the development. For example, the InitializeComponent is included in the Web service constructor. Business logic is added to this template to provide the desired functionality via the Web service. A Build of the solution creates the relevant Web service specifics. Recall that we ran the ClassToWSDL tool in the WSP to create the WSDL file; in this case, this step is included in the build process.

To deploy the .NET based service from Visual Studio .NET IDE, load the project in the IDE environment. To deploy the Web service and launch the default browser-based client, click on Debug → Start Without Debugging. Successful operation will launch the browser as shown in Figure 3.12.

Figure 3.12. Browser-based client for a .NET Web service.

Notice http://localhost/Emp401kDOTNET/Emp401kDOTNET.asmx, the Web service URL, which is based on the Web service name. To view the WSDL of the Web service, enter the following URL in the browser or click on the Service Description link on the default page:

http://localhost/Emp401kDOTNET/Emp401kDOTNET.asmx?WSDL 

The WSDL document is displayed in the browser window as shown in Figure 3.13.

Figure 3.13. WSDL for Emp401kDOTNET.

To invoke any service method, click on its name on the default page. A page detailing the SOAP messages and HTTP request examples will appear along with the Invoke button. The page for the getFundList() method is shown in Figure 3.14.

Figure 3.14. A method page for Emp401kDOTNET.

Clicking on the Invoke button invokes the particular method for the service and displays the results. The resultant page after invoking the getFundList() method is shown in Figure 3.15.

Figure 3.15. Invoking getFundList() method of Emp401kDOTNET.

In the request and response messages sent using SOAP, a service developer has two options to package relevant XML documents. The XML documents can be embedded in the SOAP body or it could be attached to the SOAP message as an attachment.

Embedding XML Documents in SOAP Messages

Embedding an XML document in a SOAP message is a simpler option in which the relevant XML document is packaged within the SOAP body element and eventually in a SOAP envelope before the message is sent to/from the service. Due to this, the entire XML document becomes a “node” within the SOAP message (which is in XML format itself). Figure 3.16 depicts this.

Figure 3.16. XML document embedded in a SOAP message.

Thus, a SOAP-based request for employee contribution could look like this:

<soap:Envelope 
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
   <soap:Body> 
      <getEmployeeContribution xmlns="insidewebservices.com"> 
         <EmployeeID> 1001 </EmployeeID> 
      </getEmployeeContribution> 
   </soap:Body> 
</soap:Envelope> 

XML Document as a SOAP Attachment

The SOAP specification allows for attachments to SOAP messages as explained in Appendix G. In such a case, SOAP messages could be sent in multipart Multi-Purpose Internet Mail Extensions (MIME) format. The main SOAP envelope forms one part of the MIME-structured message. The XML document(s) associated with the main SOAP message are packaged as remaining parts of the message with a reference to each such attachment in the main SOAP message. Figure 3.17 depicts this message structure.

Figure 3.17. XML documents as attachments to a SOAP message.

The <Attachment> tag in a SOAP body (or header) is used to specify references any attachments associated with the specific part of the SOAP message. This reference is in the form of a Universal Resource Identifier (URI) and is specified using the attribute href. A response to the getEmployeeContribution request can thus be formatted as follows:

--MIME encapsulation boundary 
Content-Type: text/xml 
<soap:Envelope 
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 
   <soap:Body> 
      <Attachment 
          href="http://insidewebservices.com/ctrbRes.xml"/> 
      </soap:Body> 
</soap:Envelope> 

-- MIME encapsulation boundary 
Content-Type: text/xml 
Content-Location: http://insidewebservices.com/ctrbRes.xml 
<?xml version="1.0"?> 
<ContributionInfo xmlns="insidewebservices.com"> 
   <EmployeeName> Carl Cooper </EmployeeName> 
   <FundList> 
      <Fund> 
     <FundName> Growth and Income Fund </FundName> 
 <contribPercent> 50.0 </contribPercent> 
  </Fund> 
  <Fund> 
     <FundName> Tax-Free Investment Fund </FundName> 
 <contribPercent> 50.0 </contribPercent> 
  </Fund> 
   </FundList> 
</ContributionInfo> 
-- MIME encapsulation boundary--

Although more esoteric from a development perspective, SOAP messages with XML attachments provide a clear partition between information and its packaging. In addition, this technique can be used to package several related XML response documents into one MIME package as attachments to the SOAP response message.

To develop and use a DEM-based service, the service or its clients may have to generate SOAP messages themselves as the level of automation in the existing tools lacks the necessary sophistication. The Java APIs for XML Messaging (JAXM) objects can alleviate the developer from creating the necessary element structure to convert an existing XML document into a SOAP message. Refer to JAXM literature for more details.

The description of a DEM-based service differs slightly from an RPC-based service. In a WSDL document that describes a DEM-based service, several elements denote the fact that the service interacts through structured XML documents rather than built-in data types such as int and string.

... 
<definitions xmlns:s="http://www.w3.org/2001/XMLSchema" 
  xmlns:s0="http://insidewebservices.com"> 

   ... 

   <s:complexType name="ContributionInfo"> 
      <s:sequence> 
         <s:element minOccurs="1" maxOccurs="1" 
            name="EmployeeName" type="s:string" /> 
         <s:element minOccurs="1" maxOccurs="1" 
            name="FundList" type="s0:FundList" /> 
      </s:sequence> 
   </s:complexType> 

   <s:complexType name="FundList"> 
      <s:sequence> 
         <s:element minOccurs="1" maxOccurs="unbounded" 
            name="Fund" type="s0:Fund" /> 
      </s:sequence> 
   </s:complexType> 

   <s:complexType name="Fund"> 
      <s:sequence> 
         <s:element minOccurs="1" maxOccurs="1" 
            name="FundName" type="s:string" /> 
         <s:element minOccurs="1" maxOccurs="1" 
            name="contribPercent" type="s:string" /> 
      </s:sequence> 
   </s:complexType> 

   ... 
</definitions> 

... 
<soap:binding style="document" 
    transport="http://schemas.xmlsoap.org/soap/http" /> 
... 

<soap:operation soapAction="http://soapinterop.org/" 
   style="document" /> 
... 

The scalability of a Web service is determined by how well it can satisfy an increasing number of concurrent client requests. The higher the number of concurrent requests that a service can handle, the better the scalability. Of course, a single instance of a service has severely limited scalability. The deployment platform significantly affects the scalability of a service. Some deployment platforms use an application server in their infrastructure that have built-in load balancing capabilities. If a Web service platform deploys the service as a servlet or an Enterprise Java Bean (EJB), the scalability is limited by the load-managing capabilities of the underlying servlet or EJB container.

One of the promises of Web services is their ability to simplify intercompany interaction. These interactions are typically long-lived — the interactions take several hours or days to complete and generally include several round trip sub-interactions. An object-oriented (or RPC-based) approach to develop the service logic, for such a scenario, is not suitable since, generally, objects are not expected to exist that long.

A DEM-based service can provide a suitable alternative to facilitate long-lived interactions. The architecture for incorporating DEM-based services in long-lived interaction is currently undergoing evolution. After the architecture and related technologies mature, Web services can be very effective in managing long-lived interaction in both intra- and intercompany situations.

Security is a vast area that has not been fully addressed by many of the Web service platforms at this point. For business-critical applications, Web service security needs to address several issues including, but not limited to:

Several standards are being proposed to address one or more of the aforementioned issues. Notable among these standards are W3C XML Encryption, W3C XML Signature (also known as the “digital signature”), Java Security Assertion Markup Language (JSAML), Web Services Security (WS-Security), XML Key Management Services (XKMS), and XML Access Control Markup Language (XACML). The HP-WSP implements the digital signature specification. Most recently, IBM, Microsoft, and Verisign announced a supporting initiative in Web services security. Web Services-Security (WS-S) describes enhancements to the SOAP technology to provide quality of protection through message integrity, message confidentiality, and single message authentication. WS-Security also provides a general-purpose mechanism for combining security tokens with SOAP messages. It is designed to be extensible (e.g., support multiple security token formats). While many initiatives support the security requirements of Web services, as yet, no specific standard has been widely adopted.