 | Level: Introductory Reiner Kraft (rekraft@almaden.ibm.com), Senior Software Engineer, IBM Almaden Research Center
12 Feb 2002 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. 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 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.
Prerequisites 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
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
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, ProgrammingTutorials.com),
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.
 |
Conclusion 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...
Resources
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. |
Rate this page
| |
