When it comes to Web Services and .NET, many Pick people are at a loss. What is this stuff? What does it mean to our industry? What's the big deal with XML? Do we have to become a "Microsoft shop"? How can we make money with it, and how much will it cost us? How can we plug our applications into it? Have no fear, you're not alone with these questions. The rest of the IT industry is trying to understand the big picture too.

The technology has been in production for a little over two years, yet the most fundamental questions still confound professionals and lay people alike. Microsoft has done a poor job of explaining the vision of .NET. There are different definitions of .NET for developers and end-users. It's difficult to understand what it really is when explanations seem contradictory. Another source of confusion is when people hear about .NET, they hear other terms like Web Services, ASP.NET, ADO.NET, managed code, and so many others, making it tough to define the forest when there are so many different kinds of trees.

This article, and others to follow, attempts to answer many of the questions from a MultiValue perspective. My primary goal is to show how various tools fit with your business applications. I'm enthusiastic about this topic because this new shift in how we use software is largely based on making business rules available for use in new ways. The Pick marketplace is abundant with solid software, tested over many years, that will fit well with the new model. What we need are bridges that allow us to get from here to there.

It's important to note that I intentionally intend to avoid areas that have already been over-explored elsewhere. For example, some of the languages used to create Web Services will be mentioned, but implementation details won't be discussed because we first need to take a view from a higher level. At this point, it's not important to know syntax, but to understand what the code intends to accomplish. Code samples can be found readily on the Internet.

To avoid unnecessary digressions here, I've inserted asterisks* into the text to reference related notes on my web site (http://Nebula-RnD.com/Spectrum).

What Is A Web Service?

A Web Service exposes software functions, not just data, for consumption by other software. When you fill in a form on a web page and submit it, you expect the remote server to execute some function, maybe save your data, and return a response. It's generally assumed that you will be using a web browser as your client software and that you'll want the results as HTML. But what if you want to use different client software, not a browser but maybe Pick BASIC and your green-screen application?

Rather than hard coding programs on the server to exchange data with a browser, Pick BASIC application, or even a Palm Pilot, it's to the developer's advantage, and consistent with good programming practices, to keep the programs' business functions separate from the end-user/client interface. It's also to their advantage to make interfaces to their functions as standard as possible, so that anyone can understand how to call to their functions and interpret the results. The developer of the client application needs to know where to find the server, what functions are available, and what data will be passed to and returned from the functions.

Various standards are being developed to support Web Services as a common way of enabling client and server components to communicate effectively and securely. Over the years, we've seen many communication "standards". Technologies such as DCOM, CORBA, RPC, and RMI have been developed and have gone through many changes, but there are still problems with using them. Not only do they change unto themselves, but they don't interoperate - at least not without some sort of bridge. Many of these are also language or platform dependent. As a result, a company doing business with many trading partners may need to support many different interfaces. Web Services is a broad label placed on the notion that everyone should start communicating using protocols that are language and platform agnostic. We shouldn't know or care what kind of system our business associates use.

So who's using Web Services? The technology has been in development and use for a couple years but it hasn't really "taken off" yet. Industry analysts are still wondering if we're going to see a boom, or a bust in general acceptance. It seems that most companies working with Web Services now are using it to get their internal systems communicating. Larger organizations may have many different systems, and it's difficult to get all of them communicating, so Web Services are currently being used more widely over intranets and extranets. The next largest group of adopters are B2B trading partners - companies who want to do business but don't want to use EDI or custom protocols. As the mainstream IT world becomes more comfortable with the concepts and finds more uses for Web Services, we'll start seeing them more widely adopted.

To apply all this to our Pick world, one of the stigmas we face is that outsiders (and many insiders) don't know how to get data to and from our systems. The sales process can get bogged down if we get stuck discussing languages, protocols, or database models. Most savvy salespeople will tell you that they sell business application software and solutions, and these other discussions should be avoided. But when people do ask what interfaces you support, at some point answering "Web Services" may be the only answer you need at that moment. Further, when I say "the mainstream IT world", I'm including the MultiValue community as well. We have an opportunity here to follow along with a paradigm shift, rather than following behind one, as we sometimes tend to do.

How Does a Web Service Work?

I want to avoid real code, but to explain how Web Services exchange data, we can get a little more technical. In Pick BASIC you can pass a dynamic array with "Call MySub(array)", and on the other side we find "Subroutine MySub(params)". We know, because we're Pick people, that a dynamic array has attributes, values, and subvalues - and the BASIC programs know how to logically structure the data for these calls. Other people don't know these things, so we can't expect them to call our subroutines and pass us a dynamic array. To bridge the gap between different ways to represent data and to exchange this data via Web Services, we use XML. XML wraps "tags" around data to make its meaning clear. Rather than sending 12^34, we'd send 12 34. Yes, the price we pay for standardized communications is bloated data representations.

A single Web Service often provides access to multiple functions, or "methods", which equivalent to our BASIC Called subroutines. As we saw above, we can exchange dynamic arrays between our own subroutines, but XML is used between different systems. When we Call a BASIC subroutine, we expect that the Call statement will be processed by a compiled BASIC Subroutine. With a Web Service though, we have no idea what kind of system will be processing the request. We need to send the request in a format that any system should be able to understand, regardless of the platform or languages used on that system. For this, again, XML is used, but in this case, the data also includes the name of the function (method) we intend to call on the remote server. The client code, or the consumer, sends a request that looks something like this:

<server>remotename</server>
<method>functionname</method>
<data>
<onhand>12</onhand>
<onorder>34</onorder>
</data>

But wait a minute - I just made up those XML tags. We need some standards to more clearly define exactly what those tags represent so that the request can be properly routed to the server, and when the service provider receives the request, it knows exactly what to do with it. Enter SOAP. SOAP is a "standard"* that almost everyone now follows when implementing Web Services. SOAP defines the specific XML tags that are used to allow a client/consumer and a server/provider to communicate.

How do SOAP/XML requests and data move between clients and servers? Most Web Services are run through a normal web server like IIS or Apache. That sounds obvious but using an HTTP server is more of a convenience than a rule; in the future we'll see Web Services run over other protocols. For example, you could send a SOAP request via e-mail to a server that's configured for it. (SOAP over SMTP is a hotly debated topic, I'm just citing an example.) You can setup any TCP socket* to read and process SOAP requests, but the most popular way today to accept requests and return results is with an HTTP server, just like requests for web pages.

So What is .NET and it's Relationship to Web Services?

Microsoft .NET is a strategy and far reaching vision which changes the way we write and use programs. It's not a product, a language, or operating system, and most importantly, .NET is not just Microsoft's name for Web Services. One of many goals of .NET is to facilitate creation and consumption of Web Services. Web Services are just a part (big part, granted) of a much larger vision which .NET defines.

So what's the grand vision? Due to mixed messages coming from Microsoft it's a little blurry, but it does become more clear over time. Many people working with .NET every day are still having difficulty "getting it". I can tell you that after months of researching .NET-related topics, the more information I review the more "aha" moments I've had. It's like a long book that reveals its plot right up to the very end. Fortunately, this article focuses on Web Services, so I can dodge discussion of the bigger picture - for now anyway.

.NET provides different ways of working with Web Services, but .NET is only one option of many for actually implementing Web Services. To their credit, Microsoft has made it VERY easy to implement Web Services as a provider or consumer with .NET. The documentation is superb and extensive, the tools are stable, and there are countless web sites and books on the topic. Of course, Microsoft is very focused on getting everyone to use Windows, so if you're going to use their tools, you must be using Windows. What this tells us is that it's not Web Services that are platform-specific, but rather the tools that Microsoft produces for implementing Web Services that are platform-specific. If you would rather not use Microsoft's tools to provide/consume web services on Windows, there is no requirement to do so.

There are some Windows-based tools of note which take advantage of the .NET Framework* for Web Services development. If you wish to examine these tools, the .NET Framework software is very safe, co-exists in harmony with all other Windows software, and is freely downloadable from Microsoft.

The first development tool of note is Microsoft Visual Studio .NET. With a couple clicks you can create a client or server interface for existing functions. The interface is called a proxy, and functions like a translator. You tell the proxy what you want to do. The proxy translates that message into XML following SOAP guidelines, sends it via HTTP to a server, and returns the response from the server as familiar data types like strings and integers. You don't need to see any XML, or any other "foreign stuff" to consume a remote service. For a server, you write your functions, and then tell Visual Studio to expose your functions as Web Service methods on your web site. When a remote consumer executes one of your methods, the SOAP/XML translation for request and response is done behind the scenes. The question of how to provide or consume these services from your MV code will be addressed in a future article.

Next is Borland's new C#Builder. Creating a proxy for a client or server is as easy as with Visual Studio. Unlike Visual Studio, licensing for C#Builder starts at "free" for the Personal Edition - see http://www.borland.com/csharpbuilder/. In this category, Borland also has Delphi Studio and C++Builder.

Maintaining the distinction between Web Services and .NET, there are many other tools for developing Web Services clients and/or servers without .NET. Examples* include Sun ONE products from Sun Microsystems, WASP from Systinet, Komodo from ActiveState, JBuilder and Kylix from Borland, many offerings from IBM, and even more options from the open source community, to be discussed in the next article.

Summary

In this first article I've defined Web Services from a MultiValue perspective, and even if .NET hasn't been entirely defined yet, it's clear that .NET is only Microsoft's way of implementing Web Services. Other non-Microsoft implementations do exist, and you don't need to be a Microsoft shop if you want to provide or consume Web Services.

In upcoming articles I'll discuss the strategic and tactical reasons why you should or should not adopt Web Services and/or .NET. I'll go over options for coding Web Services with different languages and on different platforms. I won't provide specific code or HowTo's, understanding the many options is an adventure by itself. I'll provide information about the options available to us in the MV community, including the Pick Data Provider .NET from Raining Data, the SOAP/XML Gateway from Cromwell Business Systems, Steve Lake's freeware server component, Capillary, and others.

As we go further with this material, I hope you will start to think of your software more in terms of the value it has as a remote resource to other software, and how value can be added to your software by consuming services from other providers. Applications include inventory or shipping status; submission of orders, invoices, or claims; customer or patient address or status inquiries, and so many others.

For follow-up information to this article, including the *references, or to send your comments or questions, please visit 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