J2EE or .NET, You choose! (Part 1)

For the past few years you've heard about web services and how they are/were the wave of the future.

"Everything will be a web service!"

"You won't be able to do business with having web services for all of your data!"

And on and on. We all heard it over and over. Many companies staked their futures on web services being pervasive. Standards were established and adopted and then new standards were established and adopted. Various heavy-hitters in the industry have come forward and delivered their visions of what all of this means for consumers as well as developers.

Sun Microsystems created logical extensions to its Java programming language to embrace web services. A cross platform environment that covers the entire scope of development, from tools to deployment, Java 2 Enterprise Edition (J2EE) extends Java Standard to include technologies to make web services real.

.NET from Microsoft takes a different approach to web service. Designed specifically for the Windows platform, Microsoft's vision revolved around this single platform strategy. With the Mono Project from Ximian, .NET was made available on the Linux (and other) platforms. The Microsoft concept for developers revolved around the use of easy to use tools designed to simplify the complexity of web services.

The good news for developers is that both technologies are based on many of the same standards for creating and deploying web services. While Sun and Microsoft took different approaches to web services, from development to delivery, the underlying foundations are built on similar standards, and the ability to interoperate is high.

In this first of a series on these two important technologies, we'll look at the foundations of each, the basics of how they work and some ideas on what are the considerations in using one over the other. The hope is that this first part will help you understand enough of each to be able to make the decisions needed to implement a strategy around their use.

The following two articles of the series will deal with examples of how to use each technology. Finally the last article will cover how to use the two together, a scenario most likely to present itself in today's world. This interoperation between the two is likely to be more effective and to utilize existing resources best.

A bit of History and today's Landscape

Businesses today have greater and greater need to be able to interact and exchange information and data with customers, suppliers and partners. The times of isolating a business are gone. Consolidation, mergers, and an extremely competitive arena make the leveraging of assets between the various layers of the business model vital.

Today consumers of products and services, whether they are end users or other businesses, demand responsiveness from their suppliers, quick and easy ordering methods, track-able shipments and access to details from a variety of sources. As software developers, we must be able to design and build solutions that are able to easily integrate with the systems of other aspects of the model.

In the past data could be pulled, packaged and sent to a business partner, where typically it then had to go through some process to make it usable by the target system. Anyone who has worked as a developer in a large company will recognize this scenario. There have often been many small programs that's entire function was to take data from one format and prepare it for use in another. This created many points of possible failure and caused the need for increased maintenance. If any aspect of data on either end of the transaction changed, developers were required to make changes to the appropriate utility. Often this involved not only raw data changes, but data to be moved between non-compatible environments. The order entry system might be hosted on a mainframe computer while aspects of the accounting system ran on PC's. The basic problem with making systems like these communicate is that they were not designed with communication with external systems as an aspect of their use.

So, exactly what is a Web Service?

You might find very differing definitions what exactly what a web service is but we'll put forward a basic definition from which to base the remainder of these discussions.

Web Service. A piece of program logic that uses standards-based methods for the communications of data between sources and resources.

Now that's pretty vague and requires quite a bit of explanation to really mean much.

Let's examine some of the standards used in web services so that this will become clearer.

XML (http://www.w3.org/XML/)
At the very heart of web service (and many other aspects of data today) is XML. XML is an acronym for eXtensible Markup Language. This name for the technology is actually a bit misleading because XML isn't exactly a language but more of definition for creating a language. XML is based on SGML, a long time standard for formatting published content. It is also related to HTML (seeing a pattern here with all of these ML's). XML, SGML and HTML are all used for the creation and delivery of content. In their own areas they provide developers with ways to effectively present content to consumers of the content. The key point to remember about XML is that it only defines how a developer defines data. XML itself has no tags for data definition; it is only the definition of how to define the data. Clear, clear as mud!! To really understand XML further definition and examples are needed.

XML's main strength as the foundation for building web services is that it is structured such that it is easy for data to be passed from one application to another and without lose of content.

Much like HTML, XML is designed around the concept of special designators or "tags" defining how data is to be handled or presented. While HTML is concerned primarily with the display of content, XML is designed to define the data itself. Two important things to remember about XML tags is that XML is considered well-formed because the tag structure must follow a set of rules and by design XML is self-defining. By self-defining it is meant that the tag names themselves are descriptive of the data contained with the tag.

The well-formed aspect of XML revolves around the adherence to a strict set of rules including the requirement that all tags must include a terminating tag and well as the opening tag. Those who use HTML will recognize this as a much stricter set of rules than those for HTML. Here are some examples of an XML tag sets:
<book>
<booktitle>Moby Dick</booktitle>
<author>Herman Melville</author>
</book>
As you can see by using descriptive tag names, the data stored in XML format is fairly human readable. And you will notice the closing tag of the tag pair. If this closing tag were omitted the XML would be invalid and unreadable by an XML parser.

SOAP (http://www.w3.org/TR/soap/)
While XML defines the format for data to be transmitted by a web service, SOAP (Simple Object Access Protocol) defines a structure for transmitting the data over HTTP. The advantage of using HTTP is that it is such a widely recognized protocol and is available nearly everywhere. SOAP is based on the use of XML to build and describe the contents of messages that will contain XML data. By using a standard like SOAP, builder of web services can insure that there service can be consumed by any client that recognizes and support SOAP as transfer method.

Here is a short example of a SOAP based message. You'll notice that it follows the XML standard for well-formedness and structure.

There are a number of elements that can form a SOAP message, the above example illustrates on of those elements, the SOAP envelope. This is the outermost aspect of a SOAP message and is used the package the message for further processing. One point to understand about SOAP is that while it is defined as a protocol, it does still require an underlying physical method to actually perform the movement of the messages through the network.

The above link will provide you with access to the latest SOAP standards from the W3C.

WSDL (Web Services Description Language) is the standard used to describe what a web service is capable of doing. WSDL is again based on XML which allows it to be extended and available in nearly any situation. The description provided using WSDL allows a consumer of the web service to understand exactly how to interface with the web service and utilize its capabilities.

By using the WSDL of a web service a developer can create a client that understands and uses the functionality built into the web service. These interfaces allow the developer using XML to send data (parameters, etc) to the web service and to receive back the results of the process done by the service.

When a web service supplies a WSDL interface, it can be used by any consumer accessing the WSDL without need for direct knowledge by the consumer of where and how the web services functions. Using WSDL and other aspects of web services, a developer can find a web service that provides the functionality needed and use it without detailed knowledge of the web service. This is a vastly different paradigm that traditional computing methods, where a developer needed to understand the exact workings of a system with which he was interfacing.

So if one of the advantages for web services is that a developer needn't know all the details about a service being consumed, how does one go about finding a web service that supplies what is needed?

This is where UDDI (Universal Description, Discovery and Integration) comes in. UDDI allows for registries of web service that enables a consumer needing a web service to easily, quickly and dynamically locate a web service that provides the needed functionality.

UDDI builds on XML and SOAP to provide web service providers with a way to "advertise" the availability of the service. By using UDDI, both provider and consumer have their needs satisfied.

So what does it all mean and where do you go from here?

There are a lot of aspects to web services, I've only touched on the most important and critical standards that need to be understood in order to either create of consumer web services. The links for each technology will enable you to get access the standards established for each and any many cases examples of their use. In many cases the time needed to fully understand and implement web services will be significant, but the long term benefits will be great. The flexibility and availability of web services will only increase as more businesses take advantage of the power they provide.

More and more businesses and consumers are looking for more and more information and data. Web services provide the ability to share data across many different infrastructures with any number of users and user types. Whether business to business, business to customer or business to supplier, the benefits to each are great.

If you are considering creating and using web services a very important site to visit is WS-I (http://www.ws-i.org). WS-I is not a standards group, but rather an organization comprised of many of the major vendors in the web services space who have organized to define what is needed to insure interoperability between web services.

The WS-I provides guidelines, rules, tools and examples to insure that web services are capable of interacting properly. The guidelines provided define what aspects of each of the technology specifications should be followed to enable interoperability. The basic profiles delivered by WS-I include examples and tools that allow developers to test their web services against these basic requirements.

There is a lot to web services, more that could be covered by many articles here. Hopefully this article will point you in the right direction to help you understand web services and enable you to begin to formulate a web service plan.

The next article in this series will detail Microsoft's .NET (and the Mono project) and how it implements and delivers web services through developers.