Jump to content

Archive for the 'Products' Category

HydraSDO for XML with FpML Example

Thursday, July 3rd, 2008

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

#include <iostream>
#include <string>

#include <rwsf/sdo/DataFactory.h>
#include <rwsf/sdo/DataGraph.h>
#include <rwsf/sdo/DataObject.h>
#include <rwsf/sdo/DataObjectList.h>
#include <rwsf/sdo/HelperProvider.h>
#include <rwsf/sdo/PropertyList.h>
#include <rwsf/sdo/XMLDataAccessService.h>
#include <rwsf/sdo/XSDHelper.h>

using namespace rwsf;
using namespace sdo;
using namespace std;

const char* SCHEMA_FILE = “../fpml-bond-option-4-4.xsd”;
const char* INSTANCE_DOC = “../bond-option.xml”;

int main()
{
  try
  {
    // Create an XSD Helper instance for working with XML schema
    DataFactoryPtr dataFactory = DataFactory::getDataFactory();
    XSDHelperPtr xsdHelper = HelperProvider::getXSDHelper(dataFactory);

    // Define Types and Properties from the XML Schema
    xsdHelper->defineFile(SCHEMA_FILE);

    // Load the XML instance document
    XMLDataAccessService das(dataFactory);
    DataGraphPtr dataGraph = das.loadFile(INSTANCE_DOC);

    // Create a root data object
    DataObjectPtr root = dataGraph->getRootObject();
    DataObjectPtr fpmlDoc = root->getDataObject(”FpML”);

    // Get bond details
    DataObjectPtr bond = fpmlDoc->getDataObject(”trade[1]/bondOption/bond”);
    std::cout << “Instrument Id = ” << bond->getCString(”instrumentId[1]”);
    std::cout << “Currency = ” << bond->getCString(”currency”);
    std::cout << “Coupon Rate = ” << bond->getCString(”couponRate”);
    std::cout << “Maturity = ” << bond->getCString(”maturity”);
    std::cout << “Par Value = ” << bond->getCString(”parValue”);
    std::cout << “Face Amount = ” << bond->getCString(”faceAmount”);

    // Modify the Coupon Rate from 0.014 to 0.015
    bond->setCString(”couponRate”, “0.015″);

    // Save the changes to a new XML instance document
    das.save(dataGraph, “bond-option.001.xml”);

    return 0;
  }
  catch (SDORuntimeException& e)
  {
    cout << e.why() << endl;
  }
}

Architecting your Concurrency Model

Friday, March 7th, 2008

Abstraction of concurrency from software application logic

(a.k.a: “I feel the need… the need for - Concurrency…”)

From Monolith to Component Architectures

In the olden days of computing, everything was combined into a single lump of software - including operating system functions, application logic, data, user presentation. After some time, we realized that creating a separation between the hardware and the software application would be useful, and the operating system was born. Some time later, we realized that managing the data was a distinct task, and databases became a separate entity. Some time after that, we decided that it would be a good idea to split out the user interface, and the era of client/server began.

So it went, the software industry continued to evolve our architectures into more componentized and modular arrangements.

Architecting for Concurrent Computing

Now that multi-core architectures are common and the need for concurrency in software architectures well understood, the next question is how best to architect our applications and how best to structure development organizations to support them. For the moment, let’s talk about the development organization. In the past, concurrency was a task limited to edge cases, but now ubiquitous multi-core hardware is making it much more common.

There are two ways to handle this. First, train all your software developers to be experts in concurrency (yikes…). Second, have concurrency specialists to focus on making your applications parallel. Since training all of your software developers to be experts in concurrency seems daunting, it would seem that the second option is better. But if concurrency is now required through significant portion of your application architecture, how can only a few engineers or architects be responsible for it?

The answer lies in abstracting the concurrency model from the application logic. While this may not be possible for all aspects of your concurrency model, it certainly should be for some - especially for well-defined services (in the SOA definition of the word). Services can be run in multiple instances across multiple threads and multiple cores (even multiple servers) to achieve a significant degree of concurrency without rewriting the code inside the service.

To the extent that you can do this, you can allow your application developers to focus on application logic and your concurrency experts to focus on concurrency. In addition, you can gain quite a bit more flexibility to your application architecture. The more your concurrency is abstracted, the easier it is to change without affecting the application logic. It’s really just an extension of the idea of loose coupling.

The Concurrency Model

This means that the application developer does not have to be the primary owner of the concurrency model. The application developer is able to focus on the application, and a concurrency expert can design about the concurrency model, just as a DBA does with the data model - I wouldn’t be surprised if we start to see something like a Concurrency Model Architect (CMA?).

Anyway, the whole thing relies on being able to separate your concurrency model from your application logic. More on that later.

HydraSDO for Databases Launched

Tuesday, January 29th, 2008

I am very happy to announce the General Availability of HydraSDO for Databases 1.0.  We already have a “Java Edition” so this completes the set by providing support for the C++ SDO API.  The Service Data Object specification is particularly important for database access because it is the only industry standard API designed specifically for accessing data in Service Oriented Environments. HydraSDO for Databases provides a Data Access Service (DAS) for relational data that is built on SourcePro DB. This of course means that it is very, very fast – we expect it to be the fastest available in the market. It also means that existing SourcePro DB users can confidently migrate their database applications to a Service Oriented Environment. The database tools provided mean that there is no database access programming required.  HydraSDO for Databases also integrates seamlessly with HydraSCA. This is particularly important because it can be expected that relational data will be a core element of applications built using a Service Component Architecture, just as it has been in older application architectures such as client-server. HydraSDO for Databases is freely available for evaluation at our Download Center. 

HydraSDO for XML 2.2 Launched

Friday, January 25th, 2008

I am pleased to announce the General Availability of HydraSDO for XML 2.2. As the product matures and gains more widespread use, some important use cases are emerging: 

Parsing Very Large XML Documents - The industry trend of increasing large XML documents has resulted in unexpected problems with applications slowing down due to slow parsing times and increased memory usage. HydraSDO for XML includes an XML parser that has been designed to quickly parse very large XML documents, which provides an immediate boost in application performance. Using very large XML documents to share data between applications is sometimes referred to as Very Large Messaging - VLM. As a rough guide, an XML document is considered large when it is over 10 MB and very large when it is over 100 MB. The XML schema complexity is also, of course, an important factor. The problem with most XML parsers is that, unlike HydraSDO for XML, they do not scale linearly.

Efficient XML Parser Memory Usage - One of the special characteristics of the XML parser that is shipped with HydraSDO for XML is that is optimized for low memory usage. This can provide an immediate performance enhancement for some applications as well as generally reducing hardware resource requirements. In extreme cases, for very large XML documents, it can prevent applications from crashing due to the unexpectedly excessive memory usage during parsing.  As a rough guide, depending on the XML document complexity, HydraSDO for XML uses about half the memory of a typical parser.

Standardized Access for Custom Data Formats - Writing data access code for custom data formats can be time consuming and can require specialist knowledge and skills. The HydraSDO SDK can be used with HydraSDO for XML to develop the necessary custom DAS for reading and writing custom data. Providing the single, standard SDO API in both Java and C++ for disparate custom data formats saves development time and costs.   

SDO DataObject Streaming - With HydraSDO for XML, you only have to parse an XML document once to take advantage of the ability to stream the SDO DataObject between computers. Using this capability, you remove the need to parse the document repeatedly while maintaining the same simple XPath-based API to work with the data (this feature is called Distributed SDO).  

Sharing Data Between Java and C++ Applications -  HydraSDO for XML uses the SDO DataObject to efficiently share data in memory between Java and C++ applications. Depending on the nature of the shared data, the feature works well for tightly coupled applications where it significantly reduces the memory footprint compared with other methods such as SOAP or CORBA (this feature is called Shared Memory Access - SMA).

Vertical Industry XML Document Handling - the internal HydraSDO for XML test suite includes a wide range of standard industry XML documents, particularly financial services. The test suite is exceptionally extensive because Rogue Wave Software has a long history of providing high performance XML parsers aimed at enterprise developers with requirements for support for specific industry XML formats.  

Service Data Objects (SDO) Standard - SDO is the industry standard for data access in Service Oriented Architectures (SOA). The SDO standard provides access to disparate data formats through the common SDO API, which is available in both Java and C++.  SDO is the data access standard for Service Component Architecture.

HydraSDO for XML 2.2 is available for download at the Download Center.

Rogue Wave Customers Honored In InfoWorld 2008 Technology of the Year Awards

Monday, January 7th, 2008

Rogue Wave Software congratulates our customers, JackBe Corporation and seeMore Technologies, who have been honored in InfoWorld’s 2008 Technology of the Year Awards. Both JackBe and seeMore are innovative ISVs that have included Rogue Wave Software’s Service Data Object technology in their product offerings using HydraSDO for Databases.

JackBe has won the prize “Best Enterprise Mashup Platform” for Presto 1.3.1, which InfoWorld describes as:

JackBe Presto provides a sophisticated set of tools for mashing together your data on the server before delivering it to a JavaScript client. A dashboard delivery mechanism lets end users create their own mashups from data services on the Web, or consume pre-built mashups from the Presto server.

SeeMore has won the prize for the “Best Database Middleware” for the Virtual Database Server 2.8, which InfoWorld describes as:

This brilliant tool from seeMore Technologies will enable a large enterprise to gather its far-flung databases — regardless of their origins — under a single, relational roof. The Virtual Database Server seeks to provide access to just about any data source, even flat text files and highly structured COBOL databases, through standard ODBC, JDBC, or OLEDB interfaces.

Rogue Wave wishes JackBe, SeeMore, and all our customers continued success in 2008!

SourcePro Edition 10 Launched

Tuesday, December 18th, 2007

I’m very pleased to announce the General Availability of SourcePro Edition 10, a very special event for Rogue Wave Software.

SourcePro is our flagship product and the main reason why we can claim to be the market leader in enterprise C++. We are launching the tenth version of SourcePro - a significant milestone that very few application development products reach. It’s a testament to the quality of the product and a demonstration of Rogue Wave’s long term commitment to the product, especially given the recent market trends moving in favor of C++  - most notably, new language standards coming in C++0X and giving C++ the same status as Java in new SOA industry standards such as SCA and SDO.

The full GA version of the product is available for customers now and the evaluation version will be available on our Web site in February.

The Multi-Core Dilemma Goes Mainstream

Monday, December 17th, 2007

John Markoff of The New York Times published an interesting article on today entitled  “Faster Chips Are Leaving Programmers in Their Dust“.

It’s great to see that this challenge, which I’ve been calling the Multi-core Dilemma is now moving into the mainstream discussion. Of course, I was far from the first to sound the alarm here, but it’s good to see the broader discussion now taking place.  We need to be talking about these issues and delivering practical solutions.  For everyone who writes software, this is a significant challenge but also a significant opportunity.  The approach to addressing this is “concurrent computing” or simply, “Concurrency”.  

Concurrency is a discipline that will become increasingly important in software development.  In fact, expect it to be a skill that employers look for on technical resumes in the not-too-distant future. Of course, Concurrency is not new, it’s almost as old as computing itself.  But as Herb Sutter pointed out in this article in Dr. Dobbs; “The Free Lunch Is Over“, it was only required for a relatively small percentage of applications until recently.  With multi-core and many-core hardware now a reality, Concurrency is already required for a significant percentage of applications and will soon be the norm.  

As cited in the Times article, several companies, including Microsoft, are working on new programming languages that are designed from the ground-up for Concurrency.  That is undoubtedly the right direction, but these efforts are years from being mainstream technology.  When they are ready, they are likely to be applicable mostly to new development - new code will be concurrent from the start.  But where does this leave the billions (yes, billions with a “B”) of lines of code that businesses already have running in their data centers?

There are a variety of threading packages available, including Rogue Wave’s SourcePro Threads for building concurrent applications. These tools make the process easier by handling much of the threading work so that software developers don’t have to. But even with these it is complex and there is still a lot of design and testing work to be done. Testing multi-threaded applications is tricky. Even with thorough testing, problems often don’t arise until the application is in production.There are many factors to consider in the Concurrency discussion, but here is one aspect to consider. With the widening adoption of Service Oriented Architectures (SOA), we need to address Concurrency at the inter-service level as well as intra-service. Threading libraries and packages are well established approaches for intra-service, but there aren’t a lot of good solutions for inter-service Concurrency other than things like clusters - but that is a blunt instrument for this task.

Concurrency at the service level (inter-service) can have several benefits.First, this approach has the affect of abstracting the Concurrency model away from the application logic. This “loose coupling of concurrency” makes it easier to change your concurrency model - such as when you move from a 4-core to a 16-core server - without touching your application code. Second, it is easier to apply to existing applications since it treats the individual service largely as a black box. Third, it can provide the scale-out that traditionally came from clustering but with much more intelligence, since the application logic is part of the mix.

In summary, there are several important needs here that have not been adequately addressed:
1. Solutions that apply Concurrency to existing applications without significant rewriting
2. Inter-service Concurrency to abstract the Concurrency model from the application code

More on this later…

Standard C++ Library now an Apache Top Level Project

Friday, December 14th, 2007

The new SourcePro release scheduled for launch next week includes the Apache C++ Standard Library (stdcxx), which has recently been promoted to Top Level Project status by the Apache Software Foundation after over two years in incubation (you can read the project history here). Rogue Wave Software is the primary sponsor of this project, which is based on our own standard library. There are many companies with products that have been opened, but few ever achieve the status of being an Apache project. It takes a lot of work to get a project out of incubation and to the status of being a full Apache project.

It’s a big achievement and the primary driver from Rogue Wave Software has been Martin Sebor - congratulations, Martin!

Welcome to the Rogue Wave Software Blog

Wednesday, December 12th, 2007

Welcome to the Rogue Wave Software blog. We’d like to take the opportunity to let you know how it all started.

Rogue Wave Software was founded in the late 1980s by Dr. Tom Keffer, a faculty member of Woods Hole Oceanographic Institute. He named the company after his sailboat.

The first commercial Rogue Wave product was based on a University of Washington project, the Data Analysis and Interactive Modeling System (DAIMS), which was the first attempt at solving large numerical problems in C++. It was launched under the name Math.h++, which can now be found, still going strong, as part of SourcePro Analysis.

The product was quickly expanded into broader class libraries with the launch of Tools.h++ in 1990 as the answer for a general data structure library for C++. Tools.h++ is also still in widespread use as part of SourcePro.

It was Dr. Keffer’s systematic approach as a scientist that resulted in the now legandary reliability and performance of these first two products. This focus provided the basis for everything that has come later. They effectively decided the product direction and roadmap for over 15 years: high performance enterprise application development in C++.

So as C++ applications continue to evolve over time to be part of Service Oriented Architectures, we will be there supporting our customers by providing the reliability and performance they have come to expect.