|
WS-I is an initiative to promote web-service interoperability across platforms and programming languages.
February 01, 2004
URL:http://www.drdobbs.com/web-development/interoperable-web-services/184405547
Arulazi is a senior software engineer for Hewlett-Packard, India. He can be reached at [email protected].
Using the WS-I Basic Profile 1.0 in Development
The Web Services-Interoperability (WS-I) organization is an open industry initiative promoting web services interoperability across platforms, operating systems, and programming languages. This initiative is supported by vendors ranging from BEA Systems, IBM, and Microsoft, to Bowstreet, Oracle, and Sun Microsystems, among others. WS-I (http://www.ws-i.org/) is gaining momentum, as the need for interoperable web services becomes more and more apparent.
With the approval of the Basic Profile 1.0 specification (http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm), WS-I has passed a significant milestone in its commitment towards interoperability. Moreover, WS-I has released the final version of its Testing Tools Implementation for the Basic Profile Version 1.0. These tools (http://www.ws-i.org/implementation.aspx) help you determine whether your web services are compliant to the WS-I Basic Profile, which considers the core set of specifications—XML 1.0, XML Schemas Parts 1 and 2, HTTP/1.1, WSDL 1.1, UDDI 2.0, and SOAP 1.1. In this article, I examine the WS-I Basic Profile and use the WS-I Testing Tools to test WS-I conformance of the publicly hosted Catalogue Web Service.
With the rapid adoption of web services, service providers and consumers are encountering interoperability issues due to the adoption of many web-service specifications that are still works in progress. Even as you read this, the WS-I is gathering input from vendors who want a smooth adoption of this technology. With the requirements from industry and practitioners, the WS-I consortium has delivered key specifications and tools that are useful in certifying as "WS-I Compliant." Among the current WS-I deliverables are profiles, use cases and usage scenarios, sample code and applications, and test suites and supporting materials that help you certify your web services or products as interoperable.
For instance, Figure 1 illustrates the components of a typical Service-Oriented Architecture (SOA). In the Basic Profile, WS-I addresses the standards that describe services through WSDL, discover services through UDDI, and invoke them through SOAP/HTTP. The interactions between these components are standardized through protocols such as XML and HTTP.
Conformance adheres to the specifications that make up a profile's "scope" and "requirement." Scope defines the versioned specifications that are referenced in defining the profile, while requirement defines the rules that web services should adhere to meet the profile's standard for interoperability. Table 1 lists some of the basic requirements captured in the Basic Profile 1.0 specification.
There are two types of conformance:
WS-I Testing Tools evaluate the web services for Basic Profile conformance by capturing the interaction between the web service and its consumers. The core components of testing-tools architecture are the monitor, analyzer, and configuration files. The responsibility of the Monitor component (Figure 2) is to capture messages and record them for future analysis. The analyzer component (Figure 3) confirms that the web-service artifacts comply with the Basic Profile. The analyzer verifies the recorded messages for profile conformance. In addition to this, there are configuration files (such as monitorConfig.xml, analyzerConfig.xml, and BasicProfileTestAssertions.xml) that control the execution of the test environment. The analyzer generates a conformance report that has the complete analysis of the web service being tested. This report helps in certifying web-service compliance to the Basic Profile.
You can download the WSI-Testing Tools 1.0 (available for both C# and Java) from http://www.ws-i.org/implementation.aspx and extract the distribution to your hard drive (for instance, C:\wsi-test-tools). For the purposes of illustration, I use here the Java implementation, and to test an example WSDL artifact for conformance, I use the HP Catalogue Web Service (WSDL document available at http://www.lixusnet.com/lixusnet/ HPcatalog.jws?wsdl).
Listing One is a sample monitor configuration file that logs the interactions between the HP Catalogue Web Service and the client. The log file contains the request to the web service and response from the web service. This is an XML document, which can be viewed in HTML format with the supplied XSL document (C:/wsi-test-tools/common/xsl/log.xsl).
The analyzer determines whether the artifacts conform to the basic profile with the help of test assertions. One or more basic profile requirements form the test assertion. In this example, I consider the HP Catalogue Web Service description to be verified for conformance. Listing Two is the sample configuration file for analyzer. The input to this tool is the location of the WSDL document for the web service and its service and port names. The analyzer processes this artifact against the test assertions document and produces the conformance report. This report (available electronically; see "Resource Center," page 5) is an XML document and can be viewed as HTML with the supplied XSL document (C:/wsi-test-tools/common/ xsl/report.xsl).
The conformance report for this artifact showed "failed," thus, the web service failed to comply with the test assertions WSI2108 (R2110, R2111) and WSI2406 (R2706, R2723), which target the corresponding basic profile requirements. (See BasicProfileTestAssertions.xml for more information about these failing test assertions.)
There are five result types for a test assertion:
Web-service developers need to ensure that they follow WS-I requirements to achieve conformance to the Basic Profile. Today, you can certify your web services with the tools provided by WS-I. In the future, development environments will be smart enough to create web services that fulfill these profile requirements, thus increasing productivity and reducing time to deliver interoperable web services.
DDJ
<wsi-monConfig:configuration xmlns:wsi-monConfig=
"http://www.ws-i.org/testing/2003/03/monitorConfig/">
<wsi-monConfig:comment>
This configuration file is used to test the WS-I sample
applications running on a single system.
</wsi-monConfig:comment>
<wsi-monConfig:logFile replace="true" location="log.xml">
<wsi-monConfig:addStyleSheet href=
"C;/wsi-test-tools/common/xsl/log.xsl" type="text/xsl"/>
</wsi-monConfig:logFile>
<wsi-monConfig:logDuration>600</wsi-monConfig:logDuration>
<wsi-monConfig:cleanupTimeoutSeconds>3</wsi-monConfig:cleanupTimeoutSeconds>
<wsi-monConfig:manInTheMiddle>
<wsi-monConfig:redirect>
<wsi-monConfig:comment>This is a redirect for HP Catalog service.
</wsi-monConfig:comment>
<wsi-monConfig:listenPort>4040</wsi-monConfig:listenPort>
<wsi-monConfig:schemeAndHostPort>
http://www.lixusnet.com</wsi-monConfig:schemeAndHostPort>
<wsi-monConfig:maxConnections>1000</wsi-monConfig:maxConnections>
<wsi-monConfig:readTimeoutSeconds>15</wsi-monConfig:readTimeoutSeconds>
</wsi-monConfig:redirect>
</wsi-monConfig:manInTheMiddle>
</wsi-monConfig:configuration>
<wsi-analyzerConfig:configuration name="Sample Basic Profile
Analyzer Configuration"
xmlns:wsi-analyzerConfig=
"http://www.ws-i.org/testing/2003/03/analyzerConfig/">
<wsi-analyzerConfig:description>
This configuration file is for HP catalog service which is deployed as
an axis service at http://www.lixusnet.com/lixusnet/HPcatalog.jws.
</wsi-analyzerConfig:description>
<wsi-analyzerConfig:verbose>false</wsi-analyzerConfig:verbose>
<wsi-analyzerConfig:assertionResults type=
"all" messageEntry="true" failureMessage="true"/>
<wsi-analyzerConfig:reportFile replace=
"true" location="report.xml">
<wsi-analyzerConfig:addStyleSheet href=
" C;/wsi-test-tools/common/xsl/report.xsl" type="text/xsl"/>
</wsi-analyzerConfig:reportFile>
<wsi-analyzerConfig:testAssertionsFile>
C;/wsi-test-tools/common/profiles/BasicProfileTestAssertions.xml
</wsi-analyzerConfig:testAssertionsFile>
<wsi-analyzerConfig:logFile correlationType="endpoint">
log.xml
</wsi-analyzerConfig:logFile>
<wsi-analyzerConfig:wsdlReference>
<wsi-analyzerConfig:wsdlElement type="port"
parentElementName="HPcatalogService"
namespace="http://www.lixusnet.com/lixusnet/HPcatalog.jws">
HPcatalog
</wsi-analyzerConfig:wsdlElement>
<wsi-analyzerConfig:wsdlURI>
http://www.lixusnet.com/lixusnet/HPcatalog.jws?wsdl
</wsi-analyzerConfig:wsdlURI>
</wsi-analyzerConfig:wsdlReference>
</wsi-analyzerConfig:configuration>
Jim is a developer for MindReef and can be contacted at [email protected].
True or false? Web services that pass the WS-I Basic Profile 1.0 are guaranteed to be interoperable. If you've been working with web services using SOAP toolkits, you no doubt correctly answered "false." But if interoperability is not guaranteed, what's the point of the WS-I and its Basic Profile?
Well, the point is that even though interoperability is the primary goal of XML Web Services, it's hard to do it in practice. (In the words of computer scientist Jan L.A. Van De Snepscheut: "In theory, there is no difference between theory and practice. But, in practice, there is.") The WS-I Basic Profile 1.0 describes the lowest common denominator for interoperable web services. But toolkit implementers still have plenty of wiggle room, thanks to optionality built into the specifications that define web-service stacks like XML 1.0 with Namespaces, SOAP 1.1, WSDL 1.1, and XML Schema.
Web-service-specification development has been an exercise in inclusion. Software development factions that normally don't see eye-to-eye on programming language, data representation, communication, or much of anything, have found a common interest in XML, and the need to integrate their systems. In the interest of keeping as many factions as possible "on the bus" and not alienating any one group, shoulds, coulds, and mays have crept into the specifications. Covering everything from how XML is serialized on a wire, to data typing, message framing, and discovery, these specs were developed without specific recommendations on how they should be combined. This causes ambiguities when you look at web services as a whole. The WS-I Basic Profile 1.0, therefore, is a vertical slice through the layers of XML Web Services specs aimed at helping pragmatic developers.
Although testing offers no guarantee for interoperability, it can still tell you what is not interoperable. It is essential to pass interoperability guidelines like the WS-I Basic Profile after deployment, but more importantly, while developing or evaluating web services.
The WS-I Basic Profile 1.0 exists as a document, but it also has an executable form in the WS-I Testing Tools and in tools like SOAPscope 3.0 from MindReef (the company I work for; http://www.mindreef.com/). SOAPscope captures and analyzes SOAP messages and WSDL documents to verify that a web service conforms to the WS-I Basic Profile 1.0. More likely, it exposes problem areas that limit use, or highlight problems in already deployed services.
In practice, problems found early in development cost less to fix than problems found after deployment. Testing against the Basic Profile could help you learn that a cornerstone in your organization's new Service-Oriented Architecture has no chance of working with SOAP toolkits other than the one you chose for implementation. Or, that RPC/encoded-style services—still the simplest and most obvious starting point for many toolkits—is a dead end. This makes a strong case for running analysis tools during development, when you can still respond to potential interoperability problems.
Since SOAP toolkits are often responsible for generating WSDL and serializing messages, it's easy to fall into an "out-of-sight, out-of-mind" trap, later discovering that a particular coding practice that seemed natural in a favorite language is discouraged by the WS-I Basic Profile. Consider overloaded operation names: In Java or C#, overloaded methods are common and can clarify the intention of related methods. This practice is explicitly disallowed according to R2304 of the WS-I Basic Profile 1.0 because it introduces ambiguities in a message's wire signature, making it hard to tell if a message is invalid, or just intended for a different method. It can also foil toolkits that use the operation name to dispatch messages.
Passing the WS-I Basic Profile 1.0 is an essential quality metric for any web service, whether it's one you're developing, or one you're considering using. To achieving interoperability in a webservices development project:
It is important to continuously check services against the WS-I Basic Profile 1.0. With SOAPscope 3.0, select a WSDL or set of messages, and click the WS-I button. SOAPscope sets up the necessary configuration, runs the C#- or Java-based WS-I Testing Tool, and displays the resulting conformance report (Figure 4). SOAPscope also includes an analysis framework that provides more information about each problem encountered, plus an interactive view that shows you where problems are located.
DDJ
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.