MultiValue Tools

In my first article I introduced the concepts of Web Services (WS) and .NET. Article 2, "Research Before Development" shifted the focus toward Web Services, with .NET being just one implementation option.. In this third installment of a four part series, I provide examples of tools available to the MultiValue (MV) market for development and deployment of Web Services. Note that asterisks* indicate more material is available at http://Nebula RnD.com/Spectrum, where I also provide links for all tools and products mentioned here.

Tools facilitate development and deployment. If you don't mind writing a lot of code to handle small details, you may not need to buy any. In fact many Web Services are developed with freely available tools. However, you should weigh overall development costs, including time, against the cost of tools, to ensure that development funds are spent wisely.

Currently, few tools exist for MV/WS development. Seeing the plethora of tools available in the "mainstream"* world, I believe we are missing opportunities. Web Services are huge*, and rapidly growing larger as major companies worldwide continue to invest heavily. Those who provide tools today stand to reap the rewards for anticipating demands of tomorrow. Those in the business of building tools, should realize that there are opportunities for more end-to-end tools in this market. Developers shouldn't be discouraged: writing WS for MV environments isn't plug-and-play yet, but it's not rocket science either, and this article will help get you started.

The SOAP Gateway

Cromwell Business Systems (UK)
As a leading IT supplier to the independent electrical retail sector throughout the UK and Ireland, with an end-user base of over 3500, Cromwell originally developed the SOAP Gateway in collaboration with Software AG to integrate websites with their own MV application, and later totally re-developed it for resale. The SOAP Gateway is primarily a toolkit for B2B integration with MV applications, but also websites, GUI, and intranet applications. At design time, the software uses character-based screens for designing a document schema - this is the definition of the XML tags to wrap around data. In production, updates to the database trigger the engine to assemble data according to the defined schema, and transactions are queued for transmission. The data is transmitted over HTTP(S), FTP, or SMTP (e-mail). Application developers don't need to get involved with packaging/messaging protocols* like SOAP, or transport protocols. Cromwell didn't stop at building and sending data, they also built-in load balancing and MessageQueue-like* guaranteed transaction delivery. (Capacity Planning* is a big deal these days.) Plus, The SOAP Gateway functions as both client and server. As you'll see, these features are unique in our market.

Over 3 years of research and development are invested in this software so far. At a time when most people are still wondering what a Web Service is, this is a testament to Cromwell's forward thinking. If you need to create a solution quickly, this option should be considered for a minimum learning curve and a minimum of coding.

Capillary

Steve Lake, Royal Liverpool Hospital (UK)
This server-only WS interface for D3 isn't a product per-se, but Windows-based freeware*. It uses a special web server component* to listen for inbound requests. D3 connects as a client to this component via a socket*. (This should sound familiar to FlashCONNECT developers.) Requests run through that connection to a handler routine in D3 which passes control to BASIC business rule subroutines. The handler program also generates WSDL*, with subroutine parameters translated as arguments to WS methods. The interface uses SOAP and XML in a "black box" manner - you never need to see SOAP or XML to use it. This means you can write Pick BASIC code and let someone else deal with SOAP and XML - and that's exactly what some people want.

For freeware, this package is remarkably complete. Browser-based management pages allow for maintenance of WS methods, and for Users and Role configurations for secured access. These pages themselves use the interface to store configuration data in D3. Capillary comes with complete documentation, a tutorial, file descriptions, and samples. Since Capillary is used in real world medical applications, its quality is not surprising.

Capillary is better suited for Intranet applications than Internet. It's great software for getting started, though it is only targeted for Windows and D3*. If you're planning to write your own solution, you can learn form Capillary by using it for some in-house applications. But if you need regularly supported and enhanced cross-platform software, more complex SOAP documents, or you need to support different variations of SOAP, then you'll need more than what Capillary currently offers.

Fusionware

Mark Schramm of Fusionware Corporation will be presenting at the Spectrum Conference in March, and demonstrating a new XML server product* supporting Web Services for MV and non-MV applications. The server parses and packages XML messages using a Java middle-tier engine, with MV connectivity via ODBC or JDBC eTools. It has been designed and developed for ease-of-use and fast implementation, and uniquely supports message routing and workflow capabilities.

Sprezzatura

Revelation Software has web connectivity components* for OpenInsight which can be used for WS development, but no specific WS offering. The Sprezzatura Group*, a leading Revelation VAR, have been working successfully with the UK criminal justice system to implement Web Services with their OI application. TSG expects this to lead to a general purpose XML/Web Service enablement toolset for OI.

Other Toolkits

I was unable to find other toolkits* that provide end-to-end WS solutions for MV developers - nothing nearly as complete as The SOAP Gateway for example. However, our market has many tools which one can use to build WS solutions…

Pick Data Provider .NET

Raining Data
U2 and D3 users now share a common method of connectivity. Raining Data's Pick Data Provider .NET (PDP) is very similar to the D3 Class Library, but it supports extensive .NET features not previously available. Using a familiar architecture, there is a middle-tier listener process which forwards requests to a MV server to execute BASIC rules. PDP does not directly create or support Web Services*, but as mentioned in my first article, you can easily create a Web Service which then invokes your PDP objects - the net result is still an end-to-end Web Service solution.

RedBack

IBM
RedBack facilitates the creation of object-oriented classes. These classes have properties representing data in a U2 environment and methods representing U2 BASIC programs. After a class has been created, once again all you need is some WS code that instantiates from the class, creating a RedBack Business Object (RBO), and invokes the right methods. That WS code can be written in many languages, with or without .NET. As we'll see shortly, WebSphere from IBM can be used to provide the front-end WS integration, making RedBack one tool in a very powerful toolkit.

WebSphere

IBM
IBM is firmly behind Web Services.* Among many other features, WebSphere facilitates WS development on the "front end" and it can make use of many technologies on the "back end". Of interest to us, WebSphere can connect to U2 through RedBack or UniObjects for Java, to jBASE through Java OBjEX, or to any environment which supports a Java interface*. WebSphere has technical value to any MV installation, but there are also many business benefits* to using IBM technology - It can't hurt to adopt technology that is friendly to sales and marketing, as well as to developers.

OBjEX and jRCS

jBASE
OBjEX is a library* much like UniObjects or InterCall for U2, or the Class Library for D3: it exposes the MV environment for BASIC-like development using object-oriented languages. The architecture of jRCS, the new jBASE Remote Connectivity Services, is similar to PDP.NET and RedBack, where a middle-tier component* is used as a bridge between the client code and the MV DBMS. Despite the extra tier, jRCS reportedly has performance advantages over OBjEX. Once again code must be written to "wrap" these interfaces for WS connectivity - jRCS can be used with .NET languages, making it easy to develop and deploy such a solution.

Web Tools

MV developers commonly use web-enablement tools such as FlashCONNECT from Raining Data, jBASE Web Builder, RealWeb for Reality, Coyote from EasyCo, Viságe* from Stamina Software, or WebWizard from Eagle Rock Information Systems. While most people think of these products for generating web pages and form processing, it's better to view them as tools that return text to a web server* in response to a request from a web client. The most common application is to output HTML to a web browser, but any program can be substituted for a browser, and any text, like XML, for HTML.

As mentioned in my first article, a Web Service employs packaging and transport processes. The web tools above handle part or all of the transport via HTTP*, so all we need to think about for WS is the SOAP packaging. A Web Service requires code to parse XML, and more code to reformat results back into XML. With the object-oriented interfaces mentioned previously, the XML will probably be handled at a middle-tier, before the data is passed to the MV application, and after it is returned. But with web tools, you will probably handle the XML closer to the application. Since Pick BASIC is an excellent string handler, you can write your own XML handlers, or use external components for parsing: Pass inbound documents to external components to extract the content, process the data with BASIC code, then pass response data to another component for XML formatting.

MV as Web Service Client?

Most connectivity discussed here only supports MV platforms as a server, but what about making WS client requests from MV? There are many ways to get MV systems to make calls to remote systems. The middle-tier libraries mentioned above can be used but there are considerations.* Some MV platforms also support development using sockets.* For U2, the CallHTTP feature is available, and almost all MV platforms can call external utilities like cURL*, but you still need to deal with creating and parsing XML. Invoking Perl programs to initiate SOAP::Lite calls removes much of the burden of XML management. I've personally used various methods successfully and will mention them in my next article, "Examples of Web Services."

Summary

We've gone from a very end-to-end solution for WS development to building our own solutions with available components or even low-level sockets. Each option has its own considerations. I haven't mentioned the sensitive topic of product pricing and will leave that to vendors, but that may be a prime consideration for most developers. As I mentioned at the beginning, weigh your options wisely, the money you save now might cost you much more in development time later.

For follow-up information to this article, including the *references, or to send your comments/questions, please visit http://Nebula-RnD.com/Spectrum. If you're planning on implementing Web Services, or have already done so, I'd really like to hear from you for the next article!

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 Kick Start. He is often found in the Usenet forum, comp.databases.pick, and many other Pick-related discussion groups.

© 2007 Nebula Research and Development