Overcoming Language Barriers May Save Web Services
Some legacy languages may be called back into service as larger messages have the potential to overburden systems and performance becomes critical. Joe McKendrick considers the issues, and one possible solution, Rogue Wave’s Lightweight Enterprise Integration Framework.
Java, Visual Basic.NET, and now C# are considered the chosen few languages that will deliver us safely into the brave new world of Web services. But what about all that other code left sitting around on servers and workstations? There’s still a lot of C++, Cobol, and even RPG running our most mission-critical systems. To get to Web services, we need to migrate our code, buy a whole new system, or implement middleware that can serve as a gateway between the legacy system and the Web services.
However, migrating applications to Java or .NET isn’t always the best route. Anyone that’s migrated code knows that there’s a lot more than a recompile involved, however. Applications are built with their own specific hooks and parameters. They’re optimized for certain platforms. Many companies, for example, have C++ applications distributed all over the place, from engineering workstations to database servers. It would take a lot of money and people working overtime to move an entire block of applications to Java and .NET. Why bother? Any Web services paybacks, if any, may never recoup the investment required.
There are some voices in the industry, however, that say C++-based Web services may be a good thing for the future viability of service-oriented architectures. Cory Isaacson, president of Rogue Wave Software, one such advocate pushing for more C++ in Web services infrastructures. Rogue Wave has been supporting C++ sites for the past decade and a half with its development products. With the advent of Web services and SOA, Isaacson now sees a growing challenge that could make C++ very popular again. That is, the sizes of messages sent through Web services is increasing faster than our current systems can handle them. Message sizes in prior architectures generally ranged from one kilobyte to 50 KBs, but in SOA environments messages can easily reach 100 MBs or more.
"With the volume of Web services messages growing as well, the load is growing exponentially. Rogue Wave recently surveyed about 20 of its own largest customers, and found four out of five were dealing with message sizes larger than half a megabyte. One customer, in fact, reported messages of up to four gigabytes in size.
"
"Applications and systems built on managed-code languages such as Java and C# will simply choke on such verbosity, Isaacson believes. But a native language such as C++ can handle high volumes of large messages. “It’s very difficult for Java environments to process very large messages,” he says. “Java just can’t allocate memory nearly as efficiently as native code can.”
"
To prove his point, Isaacson points to recently compiled benchmark statistics that make his case for C++-based components built with the vendor’s Lightweight Enterprise Integration Framework, or LEIF (pronounced “leaf”) versus components built in Java. According to the benchmarks, based on tests simulating 16 simultaneous users, LEIF-based components can deliver 10KB-size files 76% faster than Java components. For a large one-megabyte file, LEIF’s performance is 1133%, or 12 times faster than Java.
Meet LEIF
Rogue Wave began shipping LEIF last year to meet what it saw as a growing market for C++ Web services development. LEIF, which is also shipped with the company’s SourcePro C++ development environment, provides a way to expose existing C++ components as Web services, or build new C++ Web services applications.
LEIF takes up very little memory at runtime – about three megabytes – and can be up and running in about 10 minutes. A significant feature in LEIF is the project wizard that guides developers through three types of project development: data tier projects, for XML data binding for C++ based on a W3C Schema file; network-tier projects, to generate WSDL documents; and service-tier projects to generate server code. Project output and HTML documentation can also be generated from the same interface. Code-generated components include sample implementation files, data files, client files, server files, deployment descriptors, and configuration files.
A key tool within LEIF is SOAPWorx, which generates class reference documentation and descriptions from WSDL files. The toolset also includes a container for testing applications called Bobcat Server, which can either run on a standalone basis or interface with Apache Server.
New Life for C++
Currently, according to Isaacson, most LEIF users are current C++ development shops that seek to extend their applications into the Web services space. Most applications being generated from LEIF at this point are already-existing applications, he adds.
"Of course, C++ once had another starring role in a component-based architecture – CORBA. However, Isaacson says the impact of Web services extends far beyond its predecessor, and C++ should be a part of that, too. “CORBA has serious limitations,” he remarks. “Web services is just a better way to do components. We think that Web services is absolutely going to be widely adopted. It’s so easy to learn and there are so many advantages to it.”
"
While LEIF is essentially the anti-Java tool, it isn’t a far leap to envision the easy-to-use functionality of such a toolset being extended to generate or repurpose other code as well. For example, Isaacson states that Rogue Wave is looking at the possibility of offering a “language-independent” toolset. “Java certainly has been tremendously successful and it’s a great programming language for business logic, but its not so good for that back-end processing,” he said. “We’re working on a language-independent set of tools, but still having the performance characteristics of native code.”
Of course, one has to wonder if it’s possible to build and run Web services componentsin C++, can native Cobol or RPG be far behind? Imagine the capacity for messaging services from a big honking iSeries or zSeries, unobstructed by a CLR or JVMcontainer.
Trackback URL for this post: http://www.webservices.org/trackback/id/5744