Introduction

Recently, IBM released the WebSphere® Studio Application Developer product, a development environment that allows you to create open, platform-neutral Web services for deployment across heterogeneous systems. Essentially, Application Developer combines the functionality that was found in VisualAge® for Java^TM and the earlier WebSphere Studio products. However, many new features, including XML tools and support for Web services, were added.

Microsoft® recently released Visual Studio® .NET, which allows developers to write, build, and test .NET applications. ASP .NET, the Common Language Runtime (CLR), documentation, samples, tools, and command-line compilers are all part of the picture.

Although both solutions are based on open standards, such as XML, SOAP, WSDL, UDDI, there are many differences between them (for example, framework, programming languages, run time, service discovery, terminology, and so forth). In my previous article, How IBM WebSphere Studio Application Developer Compares with Microsoft Visual Studio .NET -- Part 1: Conceptual Differences, I provided a high-level overview of both development environments and tools, focused specifically on how they support the development of Web services. This article describes implementation details and other differences between the two environments focusing primarily on usability of the provided tools related to the development of Web services.

The Microsoft Web services model differentiates between a Web service consumer and an XML Web service, while the IBM Web services model distinguishes among:

• Service - The actual Web service application.
• Service provider - An entity that hosts a service.
• Service interface provider - An entity, such as a standards organization or company that publishes a common reusable interface.
• Service registry - The UDDI registry, which acts as a directory for Web services.
• Service requester - The client, which binds to a particular service.

The tools provided in both environments for configuring, designing, and implementing Web services were described in Part 1. This article will now show these tools in action in sections that discuss:

• Creating a Web service - You will see how a Web service is created in each environment. There will be a description of the tools available, so you can quickly create WSDL documents without having to author everything manually (if you ever have to write a WSDL document manually, you'll appreciate these tools).
• Publishing and discovery of a Web service - Once the Web service is up and running, you may want to publish it, such as to a UDDI directory, to exploit its existence. This section will also describe how to discover existing Web services.
• Consuming a Web service - This section implements an application that consumes a Web service in each development environment, using actual StockNews and WeatherService Web services as examples.

In the first part of the article, some simple code examples simulating an integer calculator Web service will be used to illustrate how the tools work, and what files get produced as a result of using the tools. These files are provided in the download ZIP file available with this article. Later, more realistic examples will be shown when consuming existing Web services on the Web. For example, the WeatherService we will consume is a .NET Web service listed at the xMethods site of publicly accessible Web services. A WSDL for this Web service can be downloaded from the samples.zip file below. In addition, we will also consume an Apache SOAP stock quote news service that will return a list of current news about a company, when given the company's stock ticker symbol. The end of each section summarizes the main differences between the two environments, and the conclusion will summarize the learning experience I gained using both environments.

Since this article is not intended to be a tutorial on how to use WebSphere Studio Application Developer or Visual Studio .NET, some minor steps that would otherwise be covered in a detailed tutorial may be omitted.

Back to top

Prerequisites

This article assumes that you've read the first article in this series. You should have an understanding of Web services in general and the Web services stack:

• Simple Object Access Protocol (SOAP)
• Web Services Description Language (WSDL)
• Universal Discovery, Description, and Integration (UDDI)

For a good introduction to Web services, consult IBM developerWorks. Knowledge of Java development, HTTP, and XML is required. Familiarity with Web development (ASP, JavaScript, etc.), and with a previous version of Visual Studio such as Version 6.0, is helpful but not required. For the code samples, you need the .NET Framework software development kit, which is included with Visual Studio .NET or can be downloaded from MSDN. The code samples for .NET are written in C# (pronounced "C sharp," which is similar to Java), and C# tutorials are available on MSDN. However, the samples do not use advanced C# features, so an experienced Java or C++ developer can follow them easily. In case you don't have a copy WebSphere Studio Application Developer, you can also download a trial version. If you're already using .NET or Application Developer to design Web services, this article will show you the functions and possible advantages of using a different technology.

Back to top

Creating a Web service in Application Developer

First, let's take a closer look at what needs to be done to create and deploy a Java-based Web service using the WebSphere Studio Application Developer environment. Application Developer uses Java as the primary language of choice to develop Web services. The Web services development cycle of any project comprises several required steps. At the beginning, we have the choice to either start developing new Java code, or take existing Java code, extend it, and generate a WSDL interface and implementation document. This is known as a bottom-up approach. Or, we can develop the Java code according to a particular WSDL specification. This is known as a top-down approach. These are two different strategies, and which one makes more sense, will really depend on each particular situation. A combination of these two styles is the meet-in-the-middle approach. It is likely that the bottom-up and meet-in-the-middle approaches will be used most often, since there's a large amount of legacy code that organizations may want to leverage without having to start development efforts from scratch.

Once we have Java code that performs specific functionality along with the associated WSDL, the next step is to generate a server-side SOAP deployment descriptor from this WSDL. Deployment in this context is to configure a Web service in such a way that it becomes available within a hosting SOAP server. A deployment descriptor essentially associates a unique name (URN) to a service, along with the associated Java class that implements the particular service.

To do all of this, we prefer to have tools that support these development steps, since doing it manually tends to be cumbersome and error-prone. Application Developer provides wizards and tooling to achieve this. We will now walk through an example that shows how to use the main tool, the Web service wizard, to create Web services.

The Web Service wizard supports both bottom-up or top-down approaches. Given an existing Java class one can specify which methods to expose as a Web service, and the wizard will generate a WSDL service interface along with a WSDL service implementation file. In the other direction, it will take a WSDL file and create a Java skeleton template that can be used as a basis to develop the required functionality.

Here are the three basic steps:

1. Start with an existing Java class (see Calculator.java in the download file below). (In this discussion, using a simple integer-based calculator lets us focus on the tools without having to worry about additional complexity.) Once we have created a Web project, we can import the Java file into the project and compile it.
2. Invoke the Web Service wizard. Looking at Figure 1 below, we can also see the other wizards available: the Web Services client wizard and the Web Service DADX Group Configuration wizard.
   Figure 1. Create a new XML Web service
   
   
3. Select the Java class which will lead to the form displayed in Figure 2 below, specifying names and location of generated files. Here we can set a Web service URI (namespace), name the deployment file and location, and specify the WSDL file name and location.
   Figure 2. Configure the Java bean as a Web service
   
   

Once these steps are completed, Application Developer will prompt us with some additional optional forms that let us manipulate data bindings, SOAP or XML encodings, and more. If we wish, for example, we can specify which methods we may want to expose as a Web service (see Figure 3 below). Other options will be displayed that relate to session management (Web service scope). For instance, we can have a Web service that instantiates objects per request, one that keeps track of a user session (similar to cookies) over subsequent requests, or an object that gets constructed for the lifetime of the server.

Furthermore, we can select to have a proxy and a sample application generated, which is useful for testing purposes. Application Developer will automatically generate the necessary JavaServer Page^TM (JSP^TM) files, along with a Java proxy class that can be used to test our service. In general, the concept of a Web service proxy class is intended to make it easy to invoke the Web service. One needs only to instantiate the class and invoke a desired method, and all the encoding handling and the generation of SOAP messages is handled from the proxy class.

Once we have provided all of the necessary input to the wizard, it will generate the Web service, deploy it, and run a sample for testing. Optionally, the wizard offers to publish the Web service to an UDDI registry, which we will skip in this section. As a result, we will have the following files added to our project (plus others for administrative purposes):

• CalculatorProxy.java - A proxy class that can be used as a client skeleton to access the Web service (see the download file below).
• TestClient.jsp - Sample JSP page that can be used to test the service in a Web browser.
• Calculator.isd - Contains the deployment information once the Web service wizard is completed (see the download file).
• Calculator-binding.wsdl - WSDL service interface (see the download file).
• Calculator-service.wsdl - WSDL service implementation to import the Calculator-binding.wsdl service interface (see the download file).
• dds.xml - SOAP deployment descriptor (see the download file).

WSDL allows the inclusion of files using an "import" directive. Separating the service interface definition and the service implementation into two WSDL files facilitates reuse. Visual Studio .NET will by default only generate one WSDL file per Web service, and therefore does not make use of the import directive. Conversely, WebSphere Studio Application Developer will generate two WSDL files by default, separating service interface and service implementation. This once led to interoperability problems between Application Developer clients and .NET Web services, since Application Developer clients expect two WSDL files for a Web service. To work around this problem, one needed to manually split a WSDL file generated from .NET into two files and connect them using the import statement. Since then, this issue has been resolved and in the most recent versions of both products, this is no longer a problem. A good article that points out general interoperability issues when integrating Web service implementations from multiple vendors is Understanding Web service interoperability.

Running the JSP page in a Web browser shows the exposed methods (such as add(), sub(), mul() and div()). Application Developer comes with a version of WebSphere Application Server that can be used for local testing. By entering test values in the JSP form, we can see whether the service is working as expected (see Figure 5 below).

In summary, creating a Web service can be done easily using the WebSphere Studio Application Developer Web service wizard to guide you through the steps. We can either use a bottom-up approach with existing Java classes to generate the WSDL files, or work in a top-down direction.

Back to top

Creating a Web service in Visual Studio .NET

Web services in Visual Studio .NET are primarily developed using ASP .NET. As mentioned earlier, the file extension for a Web service is .asmx. A recent improvement in ASP .NET lets a developer separate the HTML from the code, which is different from the previous version of Active Server Pages (ASP), where HTML and code were combined in one file. When creating a new project, a Web service is basically created by selecting ASP .NET Web Service, which then automatically creates all necessary files within the project (References, Web References, Assembly Info, DISCO file). We will develop a simple integer Calculator service in a few steps that accepts SOAP, HTTP-GET, or HTTP-POST.

The sample Calculator code, Calculator.cs (see the download file), is a C# class with four methods (add, sub, mul, div). Each of the methods is labeled as aWebMethod. This means that the method is accessible as a Web service method. Exposing a method in C# as a Web service method is easy: you simply use a predefined attribute [WebMethod] in front of the method declaration:

[WebMethod]  
publicint add(int nOp1, int nOp2) {  
   return nOp1+nOp2;  
}

This ensures that the method is accessible using SOAP, HTTP-GET, and HTTP-POST. The WSDL file, Calculator.wsdl (see the download file), will be automatically constructed from the underlying .NET tools, and can be obtained by appending ?WSDL to the URL of the Web service, as in: http://myserver.com/WebService01/Calculator.asmx?WSDL.

Visual Studio .NET adds a method marked as WebMethod to the WSDL of the Web service. Using the generated WSDL file lets you easily build clients that consume the Web service, since the WSDL describes the interface to access the service in detail. The WSDL is also needed for auto-completion, a feature of Visual Studio .NET that facilitates editing of the code (IntelliSense^TM). So far, we developed some code, and then used it to generate the WSDL using a bottom-up approach.

Similar to WebSphere Studio Application Developer, we can use the top-down approach for development using an existing interface in the form of a WSDL file. First, a WSDL file needs to be converted into a proxy class before we can work with it locally. The IDE will do all of this work in the background for you by using the concept of a Web Reference. A Web Reference is essentially a generated proxy class that locally represents the exposed functionality of a Web service. Visual Studio .NET provides a tool that helps to automatically import Web references. More on this later when we discuss consuming Web services. Unfortunately, Visual Studio .NET will not create a C# class skeleton (similar to Application Developer's Java bean skeleton) that can be used as a basis for further development.

We can see that there's little effort in creating a Web service with Visual Studio .NET. There are more opportunities to fine-tune and influence SOAP by using C# language attributes. Attributes are used to associate declarative information with C# code (types, methods, properties, and so forth). Once associated with a program entity, an attribute can be queried at run time and used in any number of ways (for example, help documentation).

If you do a Build all from the menu, the code will be compiled, and then you'll be able to test the Web service. One of the nice features of .NET is that it provides default browser-based access to the Web service for testing purposes (see Figure 8 below). A user can then invoke a service in a browser using HTTP-GET.

Application Developer provides similar functionality based on JSP test pages. In this example, the result (25) would be displayed as XML:

<?xml version="1.0" encoding="utf-8"?> 
<int xmlns="http://mydomain.com/webservices/">25</int>

At this time, the service is already deployed, and up and running. The service is not yet published to a UDDI registry. What happens is that a DISCO file is first created in the virtual directory of the application. The main DISCO file located in the root of the Web service is then changed to contain an entry for the DISCO file of the Calculator service:

<?xmlversion="1.0"encoding="utf-8"?>   
   <dynamicDiscoveryxmlns="urn:schemas-dynamicdiscovery:disco.2000-03-17">  
      <excludepath="_vti_cnf"/> 
      <excludepath="_vti_pvt"/> 
      <excludepath="_vti_log"/> 
      <excludepath="_vti_script"/> 
      <excludepath="_vti_txt"/> 
      <excludepath="Web  References" /> 
   </dynamicDiscovery> 

Now that we have an overview of both environments, we can point out some differences between Application Developer and Visual Studio .NET in terms of how to create Web services:

• Application Developer uses specific wizards to guide users through the development process, whereas Visual Studio .NET doesn't use this wizard approach too extensively.
• Application Developer uses a file-based approach for deployment of a Web service. Visual Studio .NET introduces language extensions in the form of WebMethod attributes to mark particular methods for deployment.
• In Application Developer (as in IBM's Web Services Toolkit), there's a SOAP router component, which takes incoming SOAP requests and dispatches them to the appropriate classes that perform the work. In contrast, Visual Studio .NET uses ASP .NET to handle incoming SOAP requests. Using the extension .asmx the Internet Information Server (IIS) knows that the requested file is a ASP .NET Web service, processes either the HTTP-GET, HTTP-POST or SOAP request and invokes the implementation behind the Web service. There's no notion of a central SOAP server.

Back to top

Publishing and discovering a Web service in Application Developer

Application Developer contains an application called the IBM UDDI explorer or browser, which supports standard UDDI operations and can be used with a UDDI directory. IBM offers a public UDDI test registry that you can use to become familiar with UDDI and test UDDI operations. A first time registration is needed to use the service. Having a test registry ("sandbox") helps to keep the UDDI registry clean so it only contains production type Web services. Furthermore, the IBM UDDI registry also offers browser-based access to browse and find Web services.A good introduction and starting point to UDDI can be found at the UDDI.org site. IBM developerWorks also offers a wealth of UDDI-related articles.

The UDDI explorer in Application Developer helps to publish and find business entities, as well as find service interfaces and implementations of particular Web services. The first time a service provider wants to publish a Web service to a UDDI directory, the following need to be created:

• a business entity
• at least one business service
• binding templates
• a corresponding service type

In our example, to publish our calculator Web service there would be two steps:

1. Publish a business entity.
2. Publish the service interface and implementation.

In UDDI terminology, a binding template would correspond to the WSDL service implementation file, and a t-model (service type) would correspond to the WSDL service interface file. One nice thing we gain from the separation of interface and implementation is that if one publishes a particular interface that becomes popular, then other Web service providers could implement that interface by having a UDDI binding template containing a WSDL service implementation file that references that interface.

To invoke the UDDI explorer, simply select the Web project in Application Developer, and click on File => Export to start the export wizard. Here, you select UDDI to start the IBM UDDI explorer. This will start a local HTTP service that will communicate with the UDDI registry. The Application Developer documentation provides more details on the UDDI explorer setup and explains how to choose different UDDI registries. Figure 9 below shows the GUI for the UDDI explorer. The main idea is to provide the UDDI explorer with valid URLs that contain the service interface and/or the service implementation files. This then gets published to the UDDI registry, which makes it available for searching. Overall, it's interesting to search and browse through the registry and explore existing Web services. (A tutorial is available in the Application Developer documentation covering the entire publication process.)

Importing WSDL files discovered through UDDI is a two-step process. First, we perform a search on the UDDI registry or browse through the catalog to find a Web service that we want to use. Second, we then download and import the WSDL from the service provider's URL. These steps are supported in the UDDI explorer in one single function. As an optional step, we might want to edit the WSDL with Application Developer's integrated XML editor. We can also parse the file to find out whether it is well-formed.

Back to top

Publishing and discovering a Web service in Visual Studio .NET

UDDI-based publishing and discovery of services is integrated in Visual Studio .NET using a Web-based approach. Basically, an Internet Explorer component within Visual Studio .NET is used to display content (for example, online documentation). An extra tool like the UDDI explorer in Application Developer isn't necessary. Instead, the displayed Web pages provide all of the necessary functionality and display results within the development environment.

Within the XML Web service tab, the start page provides a search form that can be used to find particular services. This Web-based form links to Microsoft's UDDI registry (test and production). Figure 10 below shows how a search can be performed by typing in a keyword, in this case, weather service. The search result is then displayed. Creating a client for a Web service can be done easily by clicking on the link. That will add a Web reference to the current project, which automatically generates a proxy object. Furthermore, Microsoft's UDDI site offers advanced search functionality (such as business location) and other UDDI properties.

There's a separate download of the UDDI SDK on MSDN. The UDDI SDK provides an API to programmatically access UDDI registries. As an example, it provides a sample UDDI explorer application, which is similar to the UDDI explorer in Application Developer.

Publishing a service is also simple in Visual Studio .NET by using the previously used form and selecting Register a service. To store information in the UDDI test registry, a user account at the Microsoft UDDI site is required. Authentication can be done using Microsoft's .NET Passport, which might be convenient for someone who has a Hotmail account. MS Passport is built on .NET and shows how a Web service in general can be used for authentication.

The overall difference in how UDDI is integrated into Application Developer and Visual Studio .NET is that Application Developer uses a separate tool that is invoked and opened in a Web browser (UDDI explorer), whereas Visual Studio Net's approach is based on Web pages that will be displayed within the IDE. From a usability standpoint, one could argue that the UDDI integration in Visual Studio is somehow more convenient than in Application Developer. However, the UDDI explorer as a separate application offers a nice combination of search and browsing functionality for business entities, business services, and Web services that is not available in this form in Visual Studio .NET. Ideally, combining the best of both worlds would be most convenient for the user.

One problem I encountered with both solutions was in specifying a different UDDI service than the default one. For instance, I could not access the Microsoft UDDI test registry using the Application Developer UDDI explorer, and I could not open IBM's UDDI test registry successfully using the Visual Studio .NET tool. It should be possible to access an arbitrary standard UDDI registry using either tool. Application Developer allows you to open different UDDI registries by specifying an inquiry URL. Similarly, Visual Studio Net's Add Web Reference tool should support this by entering a UDDI URL. This will be explored in more detail in the next article in this series focusing on interoperability issues.

In addition to UDDI, discovery of services can be complemented using the file-based DISCO mechanism. Check out this example of a more complex DISCO file from the samples.zip file below. You will see that this file essentially represents a container for scl:contractRef elements that point to WSDL files. Another example of a comparable WSIL file comprises more structure. See the samples.zip file below. However, WSIL is not yet supported in the current versions of either Visual Studio .NET or Application Developer.

Using the file-based discovery mechanism using DISCO, a [WebServiceName].vsdisco file is automatically generated, and resides at the root of the Web server and/or the virtual directory where the Web application is hosted. This file describes what services are published on the Web server. I mentioned earlier that the file-based approach complements the UDDI approach. The key difference between these two approaches is that file-based DISCO/WSIL is distributed and decentralized, whereas UDDI relies on a central repository. In general, the Web has proven to be favorable towards decentralized designs. It will be important in the near future to arrive at a standard format.

Back to top

Consuming a Web service in Application Developer

Let's see how we can create a Web service client in Application Developer. First, we need to have a Web project. The next step is to retrieve a WSDL file of the service we want to consume. For instance, we can use UDDI to search and discover a Web service and download its WSDL, or we can simply go to a Web-based directory. For our example, we will use a stock news service from the xMethods Web site. The Web service wizard can again be used to create a Web service client. However, we cannot proceed unless we have the WSDL imported in our project. Using File => Import, and then HTTP allows us to download the WSDL file. It will then be added to the local project, making it available in the Web service client wizard.

From here, the steps are similar to those we followed when creating a Web service. The only major difference is that we will select the Web service client wizard, which is simply a functional subset of the Web service wizard we used before. Once we select the WSDL file and create a sample application, we will click on Finish. Application Developer will then automatically generate the Java client proxy MyBubbleSoapServicesProxy.java (see the download file), create JSP test pages, and so on. To test the client, I selected (in Figure 11 below) the method getServiceResponsePublic(), and entered (in Figure 12 below) StockNews for serviceName, and IBM for inputText. The returned result, IBMStockNews (see the download file), is HTML source, showing some current news about IBM. I could now use my Web service client to build a more complex Java application to provide me with current stock news of my portfolio. This Java application would need to manage my interest profile, and use my stock news client proxy to retrieve the current news. As we can see, Application Developer provides a neat way to test and inspect the newly generated proxy class using the IBM EJB test client.

Back to top

Consuming a Web service in Visual Studio .NET

Creating a client that consumes a Web service is an easy task in Visual Studio .NET. As an example, we will again use the WeatherService Web service. To start, we will create a new Windows® application project and add a Web reference to the solution. If we right-click on References in the solution explorer, a pop-up window to Add Web reference displays (see Figure 13 below).In the address field, we can enter the URL for either a Web service, a WSDL file, a DISCO, or WSIL file,or we can select UDDI to open the UDDI search forms discussed earlier. Either way, a list of the available Web services will display on the right.Selecting Add Reference will add that Web service to the solution explorer view, download the WSDL, and automatically generate a client proxy class. Once this is done, the Web reference can be used in the code. We may then need to modify the namespace for the Web reference. In this case, however, we can keep com.vbws.www.

It is possible to change the namespace of the Web reference, if necessary. The namespace becomes important when trying to instantiate a proxy object of the Web service. Instantiating a proxy object is one area in which the documentation is sparse, but if using C# to do this, we would write:

com.vbws.www.WeatherRetriever oWeatherRetr = new 
   com.vbws.www.WeatherRetriever();

In the next step, we simply invoke a method of the proxy object:

com.vbws.www.CurrentWeather oWeatherCond = 
   oWeatherRetr.GetWeather(txtBoxZIP.Text);

This C# code example, WeatherServiceClient.cs (see the download file), shows that it is relatively easy to consume a Web service (also check out the executable, TestWeatherService.exe (see the download file), for testing, but be aware that this requires the proper installation of the .NET framework). Figure 14 below shows the results after invoking the Web service client with the ZIP code 95120.

Some intermediary steps and details have been omitted, but the intention here is to show the concept of Web references and how they can be used to automatically generate client proxies. Furthermore, I wanted to illustrate how a Web reference can then be used to instantiate a local object that interacts with the Web service. All of the plumbing (for example, SOAP messages, XML parsing) is handled by Visual Studio .NET, allowing developers to focus on the task instead of the low level details.

Basically, creating a client-side proxy is a two step process: first, import the desired WSDL and second, invoke the Web service client proxy. Visual Studio .NET bundled these two steps into one. Once a WSDL file is specified, Visual Studio .NET imports the file as a Web reference and automatically creates the proxy. However, it does not automatically create a skeleton code class that can be used to test the client, and it does not create a sample application. As with UDDI, having the best of both worlds (Visual Studio Net's one-step client-proxy creation process with Application Developer's automatic skeleton and sample code generation) would be the most desirable.

Back to top

Conclusion

This article discussed the differences in the way two environments deal with the implementation of Web services. Both environments offer benefits in terms of rapid application development. In terms of standards implementation, both support the Web services stack, and both offer solid development tools that have matured over the past few years.

In general, it's probably a matter of personal preference which tools you choose for development. Some may prefer the wizard-style approach available in Application Developer, which offers the advantage of tighter control over parameters. Visual Studio .NET requires fewer clicks up front, but may require more time later if results need to be changed. Still, both tools facilitate the rapid development of Web services and eliminate error-prone and cumbersome tasks of manually editing SOAP messages and WSDL files.

The IBM Java-based tools provide still better platform independence. If the CLR of .NET becomes increasingly available on different platforms, this advantage may diminish. If you have no fixed platform dependencies, I recommend that you try out both and see which one better suits your needs.

Overall, there are platform and server issues. If an organization is working with a WebSphere/Apache environment, then Application Developer would be the tool of choice. If an organization uses Microsoft products (such as BackOffice, Internet Information Server, Windows 2000), then Visual Studio .NET has advantages which leverage the existing infrastructure.

Since you're now familiar with both environments, the next interesting thing is to create a more complex example that focuses on interoperability. The next article in this series will dive deeper into interoperability issues with Apache SOAP, Application Developer, and .NET. It will build on the technical background of this article, and show more detailed code samples for developing, implementing, and publishing Web services in both environments. For instance, a .NET client can consume an Application Developer Web service, that itself can act as a client to an Apache SOAP and .NET Web service. So stay tuned...

Back to top

Downloads

Name	Size	Download method
relatedfiles.zip	13 KB	FTP|HTTP
samples.zip	14 KB	FTP|HTTP

Information about download methods

Resources

• IBM WebSphere Studio Application Developer Download a trial version.
  
  
• IBM Web Services Development Concepts 1.0
  
  
• IBM developerWorks Web services zone Provides Web services tutorials, articles, and resources.
  
  
• IBM alphaWorks emerging technologies Download and try out the newest IBM technologies.
  
  
• Microsoft Developer Network (MSDN) Comprehensive resources for Windows developers.
  
  
• Microsoft Visual Studio .NET
  
  
• Microsoft ASP .NET
  
  
• Microsoft .NET Passport
  
  
• Simple Object Access Protocol (SOAP) Version 1.1 specification
  
  
• Apache SOAP
  
  
• UDDI specification
  
  
• Web Services Description Language (WSDL) 1.1 specification by Christensen, Eric, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana, W3C Note, March 2001.
  
  
• WebServices.org
  
  
• Working with Web Services in WebSphere Studio, Version 4.0 whitepaper.
  
  
• Web Services Conceptual Architecture by Kreger, Heather, May 2001.
  
  
• Inside the Common Language Runtime (CLR)
  
  
• XML
  
  
• An Introduction to GSA: Global XML Web Services Architecture
  
  
• C# Language Specification
  
  
• Java
  
  
• JavaServer Pages (JSP)
  
  
• Internet Information Server (IIS)
  
  
• xMethods
  
  
• xMethods Weather Service Web service
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Prerequisites
• Creating a Web service in Application Developer
• Creating a Web service in Visual Studio .NET
• Publishing and discovering a Web service in Application Developer
• Publishing and discovering a Web service in Visual Studio .NET
• Consuming a Web service in Application Developer
• Consuming a Web service in Visual Studio .NET
• Conclusion
• Downloads
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers