IBM WebSphere Developer Technical Journal: How IBM WebSphere Studio Application Developer Compares with Microsoft Visual Studio .NET -- Part 1

Conceptual Differences

This is Part 1 of a three-part series that compares IBM WebSphere Studio Application Developer with Microsoft Visual Studio .NET. Part 1 provides a high-level overview of both development environments and tools. The article focuses on how both environments support the development of Web services and describes how they differ conceptually.


Reiner Kraft (, Senior Software Engineer, IBM Almaden Research Center

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.

12 February 2002


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 product. However, many new features, including XML tools and support for Web services, were added.

Microsoft® also recently released Visual Studio® .NET (release candidate) to MSDN subscribers, which allows developers to write, build, and test .NET applications; ASP .NET, the Common Language Runtime, documentation, samples, tools, and command-line compilers are all part of the picture. A final version is expected in February 2002.

Although both solutions are based on open standards, such as XML, SOAP, WSDL, UDDI (baseline specifications), there are many differences between them (for example, framework, programming languages, run time, service discovery, terminology and so forth). This article, Part 1 of the series, provides a high-level overview of both development environments and tools, focused specifically on how they support the development of Web services. The goal of this article is to show you how both differ conceptually.

Previously I wrote two articles that compared IBM's WSTK/WSDE with Microsoft's Visual Studio .NET. Since then, many changes have taken place. IBM's WSTK technology concepts, including the WSDE prerelease version were adopted and integrated into the new Application Developer. Those familiar with the WSTK will see similar functionality in Application Developer. Of course, there are subtle differences. But the effort to combine all of the important development tools and technologies, such as Java, XML, Web site development, and Web services, into one IDE is an excellent move for developers. IBM's Application Developer supports Java as a primary language of choice. Today, Application Developer's GUI facilitates and eases development considerably. Also, Application Developer's Web services tools support hosting on the open source, multiplatform Apache Tomcat. This would be an important feature for users that are not working in a Windows®-based environment. Application Developer will also be available soon on Linux, so it's not just dependent on one environment.

Compared to the earlier Beta versions, there are several changes in the current release candidate of Visual Studio .NET related to Web services. Most of them were predictable changes, for instance the replacement of the Web service description language being used and the support for UDDI. In the Beta Version 2 and earlier, SDL and SCL were used to describe Web services. In the context of W3C's standardization effort on WSDL, Microsoft now uses WSDL as the language of choice to describe Web services interfaces and implementations. As for the language of use, Microsoft's .NET, with its Common Language Runtime (CLR), primarily uses C#, VB .NET, C++ (or the recently added Visual J# as a Java replacement since Java is not supported). Support for UDDI as a service directory and a discovery mechanism was also added.

It is good to see that both IBM's and Microsoft's solutions are supporting the same open standards for Web services technology (baseline specifications).

This article will provide an overview of both environments and tools to help you decide which environment is better-suited to your current Web service development needs. Part 1 will look at only the functionality related to Web services, and therefore does not compare other important parts of the IDE (for example, XML tooling). Note that the final version of Visual Studio .NET is not released yet. Due to the differences in the available versions, it is harder to do a "complete" comparison. This article takes a snapshot of what currently exists, identifies the key areas for comparison, and focuses specifically on these aspects. It does not emphasize small problems that are typical in beta releases. In the meantime, it is worthwhile to examine the current situation.

The article is divided into the following sections:

  • Conceptual Overview - Gives a high-level overview of supported concepts in IBM WebSphere Studio Application Developer and Microsoft Visual Studio .NET
  • Overview of the tools and the development environments - Examines the two development environments and introduces important tools that are provided to facilitate the development of Web services. This section also briefly discusses the system requirements, set up, and installation issues that are worth mentioning.

The article emphasizes how IBM's Application Developer and Microsoft's .NET adhere to proposed Web services standards. In particular, it discusses support for the current Web services stack (SOAP, WSDL, UDDI). At the end of each section, I have summarized the important differences.

To sum up, this article describes the experiences I have gained using both products. It is a technology update to my previous articles related to Visual Studio .NET, and adds new Application Developer topics that replace WSTK/WSDE. The goal of this article is to help developers who are just getting started developing Web services to understand both environments. For the experienced developer of one environment, it will provide a view of the other environment, and point out differences and compatibility issues between the two.


The article assumes that you are somewhat familiar with Web services and the Web services stack:

You can find many good articles on the basics of Web services at IBM developerWorks. Download a free 60-day trial version of Application Developer. For testing the environments, you should also set up the .NET Framework, which comes with the Visual Studio .NET release available to subscribers at the MSDN Web site. You can also download it from the MSDN download site. You will gain more from this article if you have some familiarity with a previous version of Visual Studio, such as Version 6.0, but this is not required. The release candidate of Visual Studio .NET is available to MSDN subscribers.

Ideally, the target developers for this article are already using either IBM WebSphere Studio Application Developer or Microsoft Visual Studio .NET to design Web services, and are curious as to how they can achieve the same (or more) using the other technology.

IBM's Web services initiatives

The recent release of WebSphere Studio Application Developer represents the results of an integration effort. The Web services functionality in Application Developer is derived from the Web services toolkit (WSTK), and it incorporates all of the experience and developer feedback that IBM has gained over time with the WSTK available to the public. IBM recently released the latest version of its toolkit, WSTK 2.4.2, on IBM alphaWorks, which comprises a variety of tools to support developers in getting started implementing and deploying Web services. This latest release provides the Web Services Stack, WS-Inspection, WebSphere 4.0 support, HTTPR demo, XKMS prototype, Web Services for Browser, and run-time and tools enhancements. In addition, IBM's alphaWorks site provides very useful tools for developers: for example, the Web Services Invocation Framework, the Lotus Web Service Enablement Kit, the Web Services Process Management Toolkit, and a Business Explorer for Web Services. The XML and Web Service development environment (WSDE) is no longer available as a separate download, since it is integrated into Application Developer. In addition, IBM developerWorks provides more resources on Web technologies and Web services. The WebSphere Studio Workbench, the brand name for the new open, portable universal tooling platform and integration technology from IBM, provides a simple way of using GUIs for developing Web services.

IBM continuously contributes, to the developer community, various new technologies related to Web services. For example:

  • Business Explorer for Web services (UDDI exploring engine)
  • Web services experiences language (WSXL), which describes the visual and interactive interface to Web services
  • Web service invocation framework (WSIF), which provides a standard API for invoking Web services
  • UDDI registry
  • Draft of HTTPR specification (a new protocol for the reliable transport of messages over the HTTP 1.1 protocol)

With the joint work on the Global XML Web Services Architecture, we can expect to see more new and interesting technologies in this area. The recently formed alliance between IBM and Microsoft -- the "Web Service Interoperability Organization" -- represents an additional step to an open industry effort to promote Web services interoperability across multiple platforms, applications, and programming languages.

Microsoft's Web services initiatives

Microsoft's .NET platform was introduced almost two years ago at their developer conference (PDC), along with their Visual Studio .NET preview release. Currently, MSDN subscribers are able to download the release candidate, and the final version is expected to ship in February 2002. The .NET platform supports the XML Web services architecture, and also incorporates more features and advances (such as ASP+, the new programming language C#, the .NET framework, CLR, and so forth). Note the term "XML" in front of Web services. This was added recently, probably to put an emphasis on XML as the underlying universal language. Microsoft also now offers the SOAP Toolkit, Version 2.0 (gold release) as a download (MSDN). This article does not provide a detailed overview of the .NET platform, and it does not provide a tutorial for Visual Studio .NET. This information is already provided as online documentation bundled with the .NET framework tools, and there are a variety of tutorials, articles and other resources on MSDN and the Web that address this topic. At this time, the ECMA has finished the standardization of the common language infrastructure of the .NET Framework and the C# programming language. Also, a beta version of Microsoft Visual J#TM .NET, a Java compatible language for the .NET platform, is available for download and testing. On the operating system side, Microsoft is working on a .NET server (currently beta 3), which integrates native support for the Web services stack, including UDDI.

Microsoft distinguishes between a set of baseline specifications that provide the foundation for application integration and aggregation (XML, SOAP, WSDL, UDDI), and the Global XML Web Services Architecture, a collection of specifications that build on the baseline specifications. IBM and Microsoft co-presented this framework at the W3C Workshop on Web Services in April 2001. A set of technical previews and proposals are available:

  • WS-Inspection (this can be used for assisting in the inspection of a site for available services).
  • WS-License (this describes how to encode X.509 certificates and Kerberos tickets, as well as arbitrary binary credentials).
  • WS-Referral (this provides a mechanism to dynamically configure SOAP nodes in a message path to define how they should handle a SOAP message).
  • WS-Routing (this enables SOAP-based protocol for routing SOAP messages in an asynchronous manner over a variety of transports like TCP, UDP and HTTP).
  • WS-Security (this describes enhancements to SOAP messaging providing three capabilities: credential exchange, message integrity and message confidentiality).
  • XLANG (business orchestration language).

In addition to these specifications, Microsoft is planning to continue releasing additional specifications in the Global XML Web Services Architecture.

Supported Web services concepts in IBM's Application Developer

In IBM's Application Developer terminology, a Web service itself is simply called a service, which represents the application. Application Developer's Web services role model is still based on the design, which was introduced with the WSTK. A service provider is an entity, which hosts the service. Then there's the service registry. The service registry acts as a service broker for Web services. A service provider can publish the services they offer. Similarly, a service interface provider may publish interfaces of services (for example, a standard organization). A service requester (client) can then query the service registry, find a desired implementation of a service, which implements a specific interface, and then bind to a service implementation. Although the terminology is different, we can still map to .NET (further .NET descriptions are provided in the next section):

  • (.NET) XML Web Service Client => (IBM) Service Requester
  • (.NET) XML Web Service => (IBM) Service, Service Provider, Service Interface Provider
  • (.NET) Directory Service => (IBM) Service Registry
Figure 1. IBM's Web services roles and interaction
IBM's Web services roles and interactions

There exist two main complementary usage scenarios and operations:

  • Find and Bind - During design time, a software developer browses or searches the service registry using the UDDI Explorer. The search result is a description of the service interfaces (WSDL), which the developer can use to build the client application. The developer can then create a Java client proxy to communicate with this Web service. Alternatively, the developer may choose to implement a Web service that complies with the WSDL definition they discovered in a UDDI Registry. In this case, the developer would use Application Developer's Web services tools to create Java skeleton implementations of the Web service and then fill in the business logic. Furthermore, the developer may choose to directly access the uddi4j API for dynamic invocation: during run time, the client application will query a UDDI registry to find out which services are available that implement the particular service interface. Once a particular service of a service provider is chosen, the client will directly bind to the service. This means that the service will be dynamically invoked by the client application to fulfill its task.
  • Publish - A service provider or a service interface provider wants to publish a service description file. As discussed earlier, a service interface provider would want to publish a service interface only, while a service provider would want to publish the implementation of the service, which points to (or imports) a specific service interface. The service provider publishes the service interface to the service registry using API functions. A service interface will be stored as a tModel (UDDI terminology), and contains a reference to the WSDL file via the <overviewURL> tag (see also Understanding WSDL in a UDDI registry for more details).

As a final step, the service provider deploys the code in a service container (application server, SOAP server), so that it can be accessed preferably using SOAP over HTTP.

In this model, there is an emphasis on distinguishing between a service interface provider and a service implementation. Since WSDL allows this separation, it is also possible to model this in .NET. WebSphere Studio Application Developer, Version 4.0.2 enables the generation of proxy classes that can consume .NET-style SOAP messages. The difference here is that Application Developer expects two WSDL files (one for service interface, one for service implementation), while .NET combines both in one WSDL file. This recent extension to Application Developer provides developers with increased interoperability between the two different platforms.

Currently, there is no support for additional discovery mechanisms, such as .NET's file-based discovery approach (DISCO). However, it remains to be seen how the proposed DISCO approach can establish itself as an open standard, or if it will be superseded by the Web Services Inspection Language (WSIL). WSIL was proposed by IBM and Microsoft to complement UDDI in advertising Web services, which is similar to the file-based discovery approach using DISCO. It might be possible that WSIL will replace DISCO, since IBM and Microsoft have announced their intentions of submitting the WSIL specification to a standards body.

Supported Web services concepts in Microsoft's .NET

Let's take a look at Microsoft's infrastructure for XML Web services (see Figure 2 below -- please note that Figure 2 is taken from the .NET documentation). There is a distinction between four infrastructure pieces:

  • XML Web Services Directories - UDDI is used as a directory of choice to provide a central location to locate Web services that are offered by other organizations. Clients send queries to UDDI using a predefined UDDI API. As a result, a URL to a discovery or Web service description document is returned. This step is optional if a client already knows a target Web service's description and location. Note that UDDI support was added in the release candidate of Visual Studio .NET, and complements the file-based DISCO. IBM and Microsoft each maintain public UDDI repositories.
  • XML Web Services Discovery - This addresses the process of locating or discovering one or more related documents that describe a particular XML Web service using the Web Services Description Language (WSDL). The file-based DISCO mechanism allows programmatic discovery (for example, using crawling technologies), and is used for locating service descriptions. Essentially, these DISCO files are placed in virtual directories of a Web server. They provide links to available Web services that are hosted on this server. Again, this step is optional if a client already knows the location and specification of a particular Web service. File-based discovery complements UDDI-based discovery.
  • XML Web Services Description - Before a client can consume or use a specific Web service, it needs to know how to interact with it (message exchange format, etc.). WSDL is used to describe Web services. Note that SDL/SDL in previous versions of Visual Studio .NET has been replaced with WSDL.
  • XML Web Services Wire Formats - SOAP (XML over HTTP) is used as the wire format for communication. SOAP is considered a lightweight protocol for exchange of information in a decentralized, distributed environment.
Figure 2. XML Web services infrastructure in .NET
XML Web services infrastructure in .NET

In .Net's concept of the Web services world, there are three entities or roles: The XML Web service client, the XML Web service itself, and the Directory Service. First, a Web service client may query a UDDI directory service for a particular service need. For example, the client is interested in a credit card verification service. UDDI provides a directory of services (yellow, white, and green pages) and search functionality through a standardized API. If a client already knows which service to use, this step is not required. Therefore, UDDI can be replaced in this infrastructure with a different type of directory service.

Second, a client requests a discovery document (DISCO file), which typically resides in a Web server's root directory per convention (in case the host is known). A discovery document contains pointers to service descriptions and locations. We can see that this file-based discovery complements UDDI, and may be used in a crawler-like fashion by clients. Again, if a client already knows about the URI of a Web service, then this step may be omitted.

The Web service client then requests the service description in the form of a WSDL document using HTTP from a known URL. The returned WSDL document contains all of the necessary technical information needed to invoke the Web service (parameter list, data types, and so on). This step is also optional for a client that already possesses the Web service description.

Lastly, the client makes a request to the XML Web service by using SOAP to communicate a message, which contains the method names to invoke, parameters, etc. The XML Web service then processes the requests, and returns a SOAP envelope that contains the computational results.

Overview of the Web services tools in IBM's Application Developer

Application Developer is a visual development environment for building Java applications, Web sites, DTDs, XML Schemas, XML, XSLT, and mapping between XML and different back-end stores. Again, I will highlight only those aspects that are relevant to Web service development. Application Developer complements WebSphere Application Server 4.0, which is used for deploying Web services. Installation is also straightforward. When you install Application Developer, a test version of WebSphere Application Server is installed for you, so that you can start developing and testing without having to worry about application server set up. Another nice thing is that both environments in this test set up can coexist on the same machine without problems. Application Developer is using port 8080 for testing, while Microsoft's Internet Information Server (IIS) is running on port 80.

Application Developer introduces "Web Services Wizards" that help facilitate the development of Web services (many tutorials are provided with Application Developer that walk through these various wizards in detail):

  • Web Services Creation Wizard - Use this wizard to create a Web service Java class, or to create Java proxy clients and JSP files to consume a Web service. As an input, it takes Java classes, enterprise beans, URLs that receive and return data, DB2® XML Extender calls. DB2 Stored Procedures, and SQL queries are supported through Document Access Definition eXtension (DADX).
  • Web Services Client Wizard - Use this wizard to create a Java client from JavaBeansTM, DADX, URLs, or stateless session EJBs that can access and test an existing deployed Web service. The model for calling Web services is based on using WSDL to create a remote Java proxy which then uses SOAP, HTTP GET or HTTP POST for the invocation mechanism (depending on the available and selected bindings).

    Note: A DADX document specifies a Web service using a set of operations that are defined by IBM's XML Extender DAD documents or SQL statements. Web services specified in a DADX file are called DADX Web services.
  • Web Services DADX Group Configuration wizard - Use this wizard to work with Web services that access DB2 and XML data stored in DB2.
  • IBM UDDI Explorer - Use this JSP application to browse a UDDI Business Registry to locate existing Web services for integration. UDDI4J is provided as a class library to provide support to interact with a UDDI registry.

We can see from the supported tools that the development environment uses Java as the main choice for developing Web services, which is a major difference between Visual Studio .NET and Application Developer.

Application Developer's Web services tools also support hosting on the open source, multiplatform Apache Tomcat, which is an important feature for users that are not working in a Windows-based environment, since .NET is currently only supported on Windows.

At this time, there is no equivalent for the UDDI Explorer in Microsoft's .NET. However, the UDDI .NET SDK 1.75 Beta that can be downloaded from the MSDN site adds support for UDDI, and comes with a UDDI explorer to demonstrate the functionality. This makes it possible in .NET to interact with a UDDI node from software or script code. It contains a class library that can be used to write UDDI clients. Once downloaded, it integrates into Visual Studio .NET. Sample code is provided that you can use to get familiar with the SDK.

Overview of the Web services tools in Microsoft's .NET

The installation process is straightforward. However, I recommend that you use a test machine for installation for various reasons (for example, since it's not final code, removing it might lead to problems when upgrading to a later version). An important requirement is Microsoft's IIS. My test machine is running on Windows XP Professional, with the latest version of IIS. Once installed, Visual Studio .NET provides a comprehensive and integrated suite of tools to facilitate the development of Web services. Most of the functionality of these tools are accessible over the provided GUI. In addition, there are some command-line versions of these tools provided with the .NET Framework (in the FrameworkSDK/bin folder).

There are many more tools that help to author XML documents, XML schemas, to address security and digital certificates, and so on. However, I will highlight only the components that address Web service development. (Between the first preview release and the recent release candidate release, there were some changes in the terminology. For example, the ASP+ run time is also known as ASP .NET, SDL, and SCL were replaced by WSDL, and the documentation also refers to the NWGS class library as .NET classes. The documentation in .NET uses both terms to refer to the same thing.)

ASP+ run time (ASP .NET) Represents a programming abstraction that allows developers to build Web services without having to deal with the underlying plumbing.

.NET class library Provides a set of useful classes to build and manipulate Web services. Web Services Description Language Tool (wsdl.exe) Generates code for XML Web services and XML Web services clients from Web Services Description Language (WSDL) contract files, XML Schema Definition (XSD) schema files, and .disco discovery documents. This tool replaces the webserviceutil.exe, which was used in earlier versions of Visual Studio .NET to generate proxy classes.

Web Services Discovery Tool (Disco.exe) Discovers the URLs of XML Web services located on a Web server, and saves documents related to each XML Web service on a local disk.

Web references A GUI that incorporates the functionality of the wsdl.exe tool. Note that with this version of Visual Studio .NET, it is no longer necessary to use a command-line tool to build a proxy class for a Web service client. Adding a Web reference to the solution will automatically generate the required proxy code that locally represents the exposed functionality of the XML Web service, and takes care of all of the necessary plumbing.

Server and Solution Explorer tool A GUI to browse Web services by network server, manage Web services projects, and deploy them automatically to a Web server.

Online documentation The documentation related to XML Web Services has matured since its previous releases.

Microsoft is targeting their new programming language, C#, as the language of choice for developing XML Web services, while IBM's Application Developer supports Java as the primary language of choice. C# looks similar to Java, but has some features not found in Java (for example, indexers, events and delegates). There a many tutorials available on the Web (for example, The C# Corner,, which teach C# in a fast pace, and also act as a language reference. In addition, there are more resources available at MSDN to help you get started with C#. This article doesn't include a tutorial on C#, but the language features that I will use in the examples should be straightforward for Java or C/C++ developers. In addition, Microsoft introduced Visual J# as a Java-compatible language targeted for the Common Language Runtime.

CLR is one of the new things in .NET. CLR allows for language independence, which means that you can choose the language of choice for coding, as long as the CLR of .NET supports the language. Currently, CLR accommodates more than 22 languages (for example, C#, VB.NET, Jscript, C++, Perl, Python, COBOL). Performance should be reasonable, since the code will be compiled to an intermediate language code (IL), and then a JIT compiler is used to convert IL into native code during run time. CLR does not support Java. (This issue is addressed with the introduction of J#.) The weakness of the CLR approach is that for it to be a truly platform-independent solution, it has to support all major platforms (Linux, Mac, etc.). Currently, only Windows 2000 and future versions of Windows are supported. This limits the versatility of .NET and the CLR to Windows at this time. Porting the .NET platform to different platforms is not an easy task, but there are efforts on porting the development platform to Linux.


To sum up, both solutions offer benefits and advantages. Both IBM's Application Developer and Microsoft's .NET comply to the recently proposed Web services standards and the baseline specifications. Both provide a plethora of tools and APIs for developing and manipulating every level of the Web services stack (UDDI, WSDL, SOAP). Microsoft's Visual Studio .NET has caught up in replacing their former SDL/SCL language with WSDL as a language to describe Web services and in its support for UDDI. It kept the file-based discovery (DISCO) to complement UDDI. There are still subtle differences of how standards are implemented and used in both. These interoperability issues are not in the scope of this article, but note that they have considerably improved over time.

One obvious (and major) difference is the support of Java as a primary language of choice in IBM's Application Developer, while Microsoft's .NET, with its CLR, primarily uses C#, VB .NET, C++ (or the recently added Visual J# as a Java replacement).

In my previous comparisons, I mentioned that the way Web services are integrated in .NET makes it fairly easy for developers to get a Web service up and running quickly. Today, IBM's Application Developer GUI facilitates and eases development considerably. Also, Application Developer's Web services tools support hosting on the open source, multiplatform Apache Tomcat. This would be an important feature for users who are not working in a Windows-based environment. Furthermore, Application Developer will be available soon on Linux, which makes it attractive to developers working on this platform, whereas Visual Studio .NET is only available on the Windows platform.

Overall, the provided tools play an important role in the development process. However, the application topology (J2EE or .NET) and the server infrastructure (WebSphere Application Server or Microsoft's IIS) with scalability and security requirements also represent an important criteria in choosing the appropriate tools.

It will be very interesting to follow the development of both environments in the upcoming months, especially with the final release of Visual Studio .NET. It can be seen that with IBM's and Microsoft's Global XML Web Services architecture, more interesting applications on top of the current Web services stack will show up gradually. This will help to foster the vision of a "programmable" Web.

My next article, Part 2, will dive deeper into the tools presented here. It will build on the technical background in this article, and show detailed code samples for developing, implementing, and publishing Web services in both environments. So stay tuned...



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=IBM WebSphere Developer Technical Journal: How IBM WebSphere Studio Application Developer Compares with Microsoft Visual Studio .NET -- Part 1