Where do we start to describe what Rogue Wave has to offer in the world of Services, Web Services, SOA or even SCA?

Firstly, it’s important to understand that Rogue Wave is a leading provider of C++ Technologies: “we make C++ look like Java”, thus helping to save the cost of implementing common programming tasks…

Secondly, it is useful to review a bit of history: When web technologies started to emerge, people turned to Java and Tomcat Servlets to create more advanced Web Interfaces. In some ways, this was the birth of J2EE & Application Servers, and one of the biggest challenges was, and still is, to integrate existing C++ server business logic with this new Java front end. People turned to JNI for in process communication or CORBA for out of process interaction.

Because those solutions can be seen as overkill, Rogue Wave offered an alternative strategy by providing a native C++ implementation of Servlets, named Bobcat that lets you directly connect your C++ to the web protocol. It may not be the best tool to create a full interactive Web GUI, but if you only have to create an HTML table from a “C++ derivative pricing computation”, spending days developing a JNI interface might not be your best way… And with “AJAX-like asynchronous web requests”, distributing them across heterogeneous nodes makes even more sense nowadays.

A few years later, during the proving grounds of XML, people were also struggling to find a good solution to “parse XML in C++”. Rogue Wave introduced XML Object Link, still the simplest C++ XML Binding solution for XML parsing. Put simply, give it a schema file (the description of what is expected in the XML data), and it will automatically generate all you need to parse, modify, create and save that data. There is no need to understand and explicitly program the parsing logic like for DOM or SAX. So if you are tasked to create a programming API to deal with a complex schema like FIXML, you ought to have a look at it.

Lastly, let’s look at the current offering:

You can’t purchase Bobcat or XML Object Link any more, but the same functionality is now available in HydraExpress, formerly known as LEIF. But Hydra Express is really a tool to create and consume web services from C++.

You start from a WSDL, and you can create a “C++ Proxy” (a class that lets you call the related service) or a “C++ Server Skeleton” (a class you can derive from to implement the service). HydraExpress also provides you with a runtime environment to deploy the newly created services. So if you have a WSDL, you can be up and running with a C++ implementation in minutes: If you have to create a new IFX interface, a new Pricing engine…etc… with logic in C++, HydraExpress is the tool for you.

After all, the Web Services promise is to make heterogeneous systems works together. So, contrary to popular belief, it doesn’t need to be all Java.

Creating independent reusable services is of great value, pretty easy to do (thanks to HydraExpress and equivalent Java technologies), but “connecting the dots” between them and making them interact has turned out to be trickier than expected.

There are a lot of reasons why building an application by “drawing arrows” in a BPM graphical tool is doomed to fail. One must be careful about Central Points of Failure, Bottlenecks, Queues, Dynamic Load Balancing, and Failover… Without these, one will fall into the same traps that led to the Myth “SOA is slow”.

For this, Rogue Wave uses HydraSCA.

HydraSCA lets you build C++, Java or Composite Services based on SCA. HydraSCA is used to implement customer solutions with a focus on performance from the get go. Dimensioning and load balancing services is a key element for achieving a performing Service Oriented Solution, and HydraSCA provides those capabilities through an advanced distribution mechanism, an optimized runtime, and a pipeline theory.

Lastly, HydraSCA relies on a standard data access technology called SDO that has triggered off-the-shelf independent products. One of them is HydraSDO for XML that lets you parse XML files using a dynamic interface (unlike Hydra Express which is static). In tests, HydraSDO for XML has been able to offer DOM like random access to data at a speed and memory consumption close to SAX.

Back when SOA was the new, big buzz word there was a lot of talk around the WS-* standards for Web services.  Our company and many other vendors providing products in the space were doing a lot of talking about which standards were relevant, when would they be needed, and how they would work within an enterprise.

 It’s been several years now since most of them were proposed, and from my experience with talking with our customers, there is not widespread adoption or even need.  The one exception to that statement would be WS-Security.  There is always a need for security, and at a basic level encryption when doing any type of messaging.  When speaking with enterprise architects and developers, security always enters the conversation at some point.  However, one that had a lot of talk in the early days but hasn’t turned out to show real demand is WS-Reliable Messaging.  We have found that most people would rather rely on their enterprise transport mechanism such as a queing or JMS implementation.  Is there real need out there for this standard and we’re simply not seeing it?

There are also standards like WS-Addressing (needed for WS-Reliable Messaging) and WS-Transaction.  Neither of these has come up in a conversation that I have had for at least a year.  Are these viable, necessary standards that vendors should strive to attain compliance to?  Are there other standards that are absolutely required to implement Web services within an enterprise environment?  I guess until the masses rise up and declare the need, they might just show up as another check-box item when evaluating vendor products.

FpML (Financial products Markup Language) is the industry standard protocol for complex financial products. It was first published in 1999 and is now managed by the ISDA (International Swaps and Derivatives Association). FpML is important because it is the XML specification for OTC (over-the-counter) derivatives and its use has increased substantially over the past few years, especially for interest rate and credit derivatives, according to a recent survey by the ISDA. The complete FpML specifications can be found on the FpML website.

Rogue Wave Software’s HydraSDO for XML product enables XML documents to be read and updated using the SDO (Service Data Objects) API which uses simple XPath notation. SDO is the industry standard for data access in a Service Oriented Architecture. HydraSDO for XML has extremely fast parsing capabilities and very low memory requirements, resulting in performance improvements for most applications. Both C++ and Java are supported, with shared memory access allowing a single copy of data to be accessed by both a C++ and a Java application.

The example below shows how a bond option FpML instance document can be read into memory, and data can be easily retrieved and modified using the Hydra SDO for XML C++ API. The instance document (bond-option.xml) is available from the FpML website.

Example