In the first article I provided a basic description of both Web Services and .NET. It's impossible to truly define technologies in one article when there are entire books covering the topics, but I hope you have a better understanding of them. These articles intend to provide information to help you make knowledgeable decisions for enhancing your business software. Once again, I have asterisks* to indicate more material is available here.

In my early research of Web Services I was baffled by the glut of new acronyms, protocols, components, and language options. Before starting development for Web Services, there are many things to know which trim your R&D time and expenses, and that's what this article is about.

The basic concept of Web Services is simple: pass messages between systems to invoke functions and return data. Implementing WS requires consideration of several layers involved in these communications. Required layers arePackaging (also called Messaging) and Transport. Optional layers include Security, Discovery, and Description. These will all be described soon.

Basic agreement between systems at each layer is required for trading partners to exchange messages. Unless both sides use compatible protocols, there is no communication. But there are still competing protocols for each layer, and competing implementations for each protocol. Variety is healthy, however our own market has many examples of inter-platform incompatibility, and we've seen that too much disparity is not healthy. Some WS implementations are more mature than others. These become the "standards". Let's take a look at examples of standards for each WS layer, and how they might apply to MV developers.

SOAP was introduced in the last article as one of the common Packaging protocols that defines an XML envelope containing a message. But you can't assume the packaging protocol is always going to be SOAP. For example, SOAP is based on an older and simpler definition, XML-RPC. If you're going to use Web Services internally or with a small number of trading partners, look into XML-RPC. The definition* is tiny compared to others, information and examples are plentiful, and it may be adequate for your needs. SOAP is the most popular packaging protocol, but why implement complex protocols unless you really need them? XML-RPC is also much easier to create and parse directly from MV code than SOAP.

It's commonly assumed that Web Services use HTTP as the Transport protocol, along with standard web page traffic. Other* protocols are available. Transport isn't about data content, but movement between systems. Unwrapping a payload from it's packaging, SOAP or XML-RPC for example, is a separate process. If you want guaranteed delivery (but perhaps not immediate) check into Message Queues (MQ) or Reliable HTTP (HTTPr) from IBM*. For asynchronous processing where there's no rush to get immediate responses, such as requesting a report to be run at month-end, SMTP (E-Mail) may be an option. Other protocols, such as Jabber, are being developed for instant messaging, but hold promise for WS applications, and BEEP is a peer-to-peer protocol which allows either side to initiate transactions once a connection is established.

Microsoft .NET has a concept called Remoting. It's an alternative to a .NET SOAP interface when both client and server support the .NET Framework, generally for single-company development over LAN or WAN, and when speed is important. Remoting allows you to invoke functions in a remote server much like a local function. This is the essence of Web Services. Data can be compressed into binary (an alternate form of packaging), removing much of the XML bloat associated with SOAP. You can also specify a "TCP" transport protocol, eliminating the overhead of the HyperText Transport Protocol.

Security is found at different levels. Clients can validate themselves with user information in the data, HTTPS can encode the entire transmission... It's up to trading partners to agree upon how much security is required and how it is implemented. The SOAP spec itself doesn't specify how to implement security at the packaging layer. There are many proposals for security standards for SOAP and various transport methods. Whatever protocols are used, compatibility is a critical factor if you intend to interface with systems other than your own. For example, IBM's Web Services ToolKit and Microsoft .NET both include support for digitally signing* and encrypting SOAP messages - but they are not yet compatible. Standards committees are discussing these issues - more on this later.

Discovery protocols use XML to create the equivalent of a digital Yellow Pages entry for Web Services, allowing client programs to find specific categories of services, then dynamically connect to consume services. An example would be a Web Service that identifies current suppliers for some product.* A consumer can use this as part of their own purchasing application, to obtain pricing, availability, warranty data, etc.. With automated discovery, the consumer doesn't know who is providing the service at run-time, and application developers don't need to know at design-time. Of course there are issues about quality of service and data, payment models, etc. These are business issues that need to be refined as the technology develops.

The most common (Description and) Discovery protocol is UDDI. There are many UDDI servers in the world, and there are other* discovery protocols, like WS-Inspection, ebXML Registry, and JXTA. If you want your services to be found on the open market, you may need to "publish" in multiple locations and formats. Most MV developers don't need discovery protocols because we do most of our business through established relationships. On the other hand, end-users may want to publish and sell their own web services, so developers should be familiar with these concepts - after all, this is all about doing business in new ways and selling new kinds of software.

Finally in our list of layers, the most common Description protocol is the Web Services Description Language. A WSDL document is XML which describes the functions a server exposes for remote consumption. There are many tools* for generating WSDL from WS programs, and generating documentation from the WSDL. There are also tools for generating WS clients based on the WSDL published on a server. Of course the link between the WS client and the business application must still be coded manually. It's not initially important to understand the tags for WSDL, but it is important to know that most services should have a valid definition available to assist developers in creating a client interface to a server.*

Languages and Component Options

Key to planning your WS strategy is the choice of programming language(s). Unless you plan to read protocol definitions and implement WS layers on your own, you will be using components created by others as part of your projects. Almost all of these components are free and developed in the open source community, but they are tied to specific languages. Using these components means learning a new language, contracting someone for this part of the integration, or using wrapper components* so you don't have to see the underlying implementation.

One such component is a well documented and maintained Perl module called SOAP::Lite*. Though the name says SOAP, the bundle includes modules for XML-RPC, UDDI, and other protocols. VARs interested in selling turnkey Perl solutions should know that until Perl6 is available, it's difficult to secure Perl code from unauthorized "migration". Otherwise, this is a great package, but requires Perl expertise.

Java developers have a wealth of tools available, primarily from the Apache Software Foundation (ASF)*, Sun Microsystems, and IBM, and the options can be very confusing. I recommend approaching your research with some guidelines. First, identify your requirements, then seek out the tools available. For example, now that you know that XML-RPC is an alternative to SOAP, you may investigate Apache XMLRPC from ASF, JAX-RPC from Sun, or find other components for XML-RPC. Second, try not to get confused by the alphabet soup of acronyms. When you come across something new, find out which WS layer the standard or component targets. For example, JAXR is for Registries/Discovery, and JAXM for Messaging/Transport - knowing this, you might want more information about JAXM, but unless you're using Discovery you won't need JAXR.

Microsoft provides free libraries to support all aspects of WS development in the .NET Framework; .NET was designed for Service Oriented Architectures. These libraries are accessible from over 20 .NET-compliant languages. Where platform independence is important, the Mono* project is an effort to create an open source implementation of the .NET Development Framework for Linux and Unix. Microsoft's SOAP Toolkit* allows creation of WS interfaces with tools like Visual Basic, but without .NET.

If you work with non-MV programming languages, I'd recommend first researching components (for packaging, transport, etc) based on the languages with which you or your colleagues are most familiar. For example, why research Apache SOAP, Axis, or Xerces (an XML Parser) if you don't plan to use Java? Save yourself the pain of protocol overload and keep your focus. On the other hand, always consider alternatives based on business requirements, stability of popular components, completeness of standards, portability, and other less personal factors.

Implementation Issues

Despite the quest for universal compatibility, problems can arise when a client and server are written with different components. Since standards are still in development, popular components are written based on assumptions and interpretations, resulting in incompatible code. Because of this, it helps to know about the components used by your trading partners. For example, .NET client/servers are incompatible with unmodified SOAP::Lite over HTTP because of different header formats. .NET and Apache SOAP also expect all method parameters to be named and typed*, which neither SOAP::Lite nor Microsoft's own SOAP Toolkit provide. It's possible to patch the MS SOAP package and change SOAP::Lite code to accommodate these issues, but it helps to know these things before they come up during testing. Developers are addressing these issues to make upcoming component versions more compatible, and standards committees try to remedy the problems in updated protocol definitions.

Many new protocol definitions are being created to fill gaps in the standards. This results in even more "standards" being developed by different groups. You'll find Sun, Microsoft, IBM, and other large companies (sometimes together, sometimes at odds) driving development of specifications and spec-compliant components. It's important to keep your designs modular so that you can change protocols without major re-writes. For example, don't build a SOAP interface directly into your application, have the app pass data to a separate routine. This allows you to choose later between SOAP, XML-RPC, or other standards.

Because this is a developing technology, some specs and components may become obsolete or replaced. For example, Apache SOAP is being replaced by Axis. This is not unusual. Be careful about coding to either obsolete or "incubating" standards.

Finally, WSDL documents are a guideline, but they may not be accurate. The convenience of WSDL tools can be deceiving. Some on the server side don't create usable definitions for remote components written with other tools, and tools that create WS clients don't understand all WSDL. Also, some do-it-yourselfers manually write their own WSDL. When in doubt, check your code, but don't hesitate to question the source.

Summary

Whomever is driving the WS agenda usually determines the technology. The burden of compatibility usually rests with the little guy. Chances are, you'll need custom code to match whatever your bigger trading partners have, even if you're doing business with many companies using other protocols. If you're one of the big guys, keep in mind the issues discussed here, make sure your specs don't impose a burden on trading partners, and try to keep open channels with developers who are trying to comply with your requirements.

The Web Service Architecture* addresses issues we've faced with its predecessors. It's not perfect, but aggressive development is in progress, and it's mature enough now for serious R&D. The variety of standards may seem chaotic, but they're really a testament to the versatility of the architecture, and I think we will see a time when differences in theory won't have so much impact on basic development.

In the third segment of this series I'll provide information about specific offerings in our MultiValue marketplace. I encourage Web Service software and service providers to contact me for possible inclusion in that article. More information can be found on my web site at http://Nebula RnD.com/Spectrum.

Tony Gravagno is founder and chief software architect of Nebula Research and Development, specializing in software and services that help developers and resellers add more value to their own offerings. Tony has been involved with the Pick market for over 20 years and has held the titles of QA Manager at Pick Systems and DBMS Product Manager at Raining Data. His latest activities include developing B2B interfaces for customers, and serving as Technical Editor for the new book from SAMS Publishing, C#Builder KickStart. He is often found in the Usenet forum, comp.databases.pick, and many other Pick-related discussion groups.

© 2007 Nebula Research and Development