 | Level: Introductory Reiner Kraft (rekraft@almaden.ibm.com), Senior Software Engineer, IBM Almaden Research Center
18 Apr 2002 This is Part 2 of a three-part series that compares IBM WebSphere Studio Application Developer with Microsoft Visual Studio .NET. Part 2 compares Application Developer with .NET, and shows how to create a Web service, publish it, and exploit its existence. 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 JavaTM 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.
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: 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.
 |
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:
- 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.
- 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
- 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.
Figure 3. Specify methods to deploy
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 PageTM (JSPTM) 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.
Figure 4. Navigator view for the Calculator project after running
the Web service wizard
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).
Figure 5. Testing the Calculator Web service
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.
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.
Figure 6. Solution Explorer view
Figure 7. Class view for Calculator class
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 (IntelliSenseTM).
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.
Figure 8. Testing Calculator Web service
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.
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:
- Publish a business entity.
- 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.)
Figure 9. Application Developer's UDDI explorer GUI supports
a hybrid approach of searching and browsing
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.
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.
Figure 10. Visual Studio .NET's UDDI search form showing search
results for a weather service query
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.
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.
Figure 11. Select method for testing
Figure 12. Testing and inspecting the client-proxy for the
stock news Web service
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.
Figure 13. Web References in Net's Solution Explorer view
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.
Figure 14. Result of Web service client invocation
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.
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...
Downloads | Name | Size | Download method |
|---|
| relatedfiles.zip | 13 KB | FTP|HTTP | | samples.zip | 14 KB | FTP|HTTP |
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 | | | Reiner Kraft is a senior software engineer at the IBM Almaden Research
Center. He was a key developer for the IBM jCentral search engine for Java resources,
which is now integrated in IBM developerWorks. He also designed and implemented
xCentral, an XML-specific search engine. His research interests are intelligent
search engines (Internet search technology), hypertext, security and Internet
information systems. You can contact Reiner at rekraft@almaden.ibm.com. |
Rate this page
| |
