This question was posed recently in an online group discussion, and I thought it was an interesting topic - so here is the response that I posted:

WOA/SOA can fit with C++ and be used to combine the agility benefits of SOA with the performance and control that C++ offers.  However, there are several things to consider.  These may not all apply to your project, depending on your business and technical requirements.

1. Developing new C++ services
- Need to support web service standards like WSDL, but SOAP is optional. REST use is growing quickly.
- May also need higher level protocols like WS-* depending on business requirements.
- Code generation tools can save significant time
- IDEs like Eclipse can also save significant time

2. Existing C++ applications
- Need to be exposed as web services so that they can work with other services without being rewritten. There are several ways to accomplish this.
- Or if the existing app is modular, it might make more sense to wrap dlls or other components as services and host in a service runtime. This may be more work but has advantages that may make it worthwhile.

3. Maintaining / managing the application
- A middleware environment that can host C++ services can make it easier to maintain
- Management tools for deploying new services will make ongoing maintenance easier.

4. Scalability & performance
- If latency is a consideration, try taking the “web” out of web services when possible.  Services running on the same server should be able to call each other in memory without marshaling to XML and going through the network stack.
- Writing code to do threading can work but is difficult to do well.  There are several new tools to help with parallel computing for C++.
- Distributing services across multiple cores or servers can help with scale out, but again consider using infrastructure as this can be very involved.

There are not as many SOA tools for C++ developers as there are for Java, but there are some good ones now so you don’t need to do this from scratch.

Patrick Leonard, VP Product Strategy & Marketing. 

Rogue Wave Software recently acquired Visual Numerics, Inc., an industry leader in advanced analytics software.  I think there are a number of interesting things about this, but one of the most interesting is the potential for new applications made possible by using advanced analytics with distributed computing.

According to IDC, the market for advanced analytics tools grew 13% in 2007.  This is being driven by a number of things, including increased demand for enterprise business intelligence like executive dashboards as well as a more data-driven approach to solving many problems from pricing of financial instruments to satellite tracking to energy exploration.  As computing power continues to increase, both in data centers and mobile devices, the ability to conduct deeper analysis will also increase.  In this way, supply (of more computing horsepower) is feeding demand (for analytical libraries).

The trick is that the supply of computing horsepower is coming in the form of distributed CPUs, not faster ones.  So increasingly, complex analysis will require a combination of powerful algorithms and distributed computing frameworks. This acquisition will give us the ability to provide our customers with this combination of technologies, as well as provide a broad array of analytics to programmers in C++, C, Java, Fortran, Python and C#. Eclipse and Visual Studio IDEs are supported.

by Patrick Leonard, VP Product Strategy

I’m flying home from visiting one of our customers, a large telecommunications company. They are using Rogue Wave(R) Hydra to create a C++ web service layer in front of their product database.

Apparently they were tired of having different internal groups all changing the common product database - picky, picky, picky… So this is a useful design pattern to them for several reasons:

• It protects the integrity of the production database by giving a web service-based, CRUD interface but controls future changes to the database schema (this has been a problem for years)
• It provides a performant programmatic web service interface for other internal applications needing access to this data - they implemented the services in C++ but could have used Java services in Hydra if they wanted to
• People writing reads & writes no longer need to know the database schema, how to join tables etc. - this is handled for them
• People writing reads & writes no longer need to worry about data validation or transactionality - this is handled for them

If you’re considering using services as the interface to your database, here are a few design & implementation thoughts to consider:

• Service granularity is above the level of the database schema so that each operation (read, write, delete, etc) handles all related tables including joins, etc.  Avoid auto-generating services from a schema or from header files, as you’ll end up with very low level services and little abstraction.
• Transactions are managed at the level of the WSDL operation so that each operation is atomic and external users simply need to call the web service and invoke the operation they need
• They used C++ web services for this because it leveraged the skills of the team and provides better performance but this approach can be done with Java or other languages
• They used Hydra’s Eclipse-based IDE for code generation of much of the service code from the WSDL interface

One developer had over 5,000 lines of C++ code completed in 5 weeks using Hydra in this project. They said that using Hydra’s Eclipse-based IDE saved a significant amount of time vs. what they were expecting.

This diagram shows a sample architecture and some design points for abstracting a production database with services.

by Patrick Leonard, VP Product Strategy

Last week I was on a panel discussion at Sun / AMD CommunityOne East in NYC about multi-core and parallelism. Representatives from Sun, AMD, Cilk Arts and Allinea were on the panel with me.

Listening to the questions, from the audience and conversations after, one thing was clear - this is a complex challenge that even smart, experienced people struggle to do well.  When moving toward developing software in a parallel environment, there are a lot of things to consider, a lot of questions come up.

How do I train my developers? 
Can I reuse what I have or do I have to rewrite?
What tools should I use? 

There are a lot of ways to dissect this problem, but one thing we all agreed on is that people should make sure that they understand the basic nature of the parallelism they are trying to achieve and why. The simplest starting point for this is determining if you are trying to “scale up” or “scale out”.  This can have implications for the architectural approach you take and other aspects of your project.

With the advent of multi-core systems, “scale up” and “scale out” don’t have the clear distinction that they used to have, but it’s still a useful starting point. Some quick definitions:

• Scale up: doing more on a single server, using a single server more efficiently
• Scale out: distributed computing, using multiple servers to increase the throughput of a system

The reason that the advent of multi-core systems has blurred the lines between “scale up” and “scale out” is that now a single server can have 4, 8, 16 or more CPU cores, so it looks more like a distributed system in itself, and that is going to more the case in the future. Still, doing parallelism on the scale of a thread pool or multi-core server is different than going parallelism across a network (or rack) of servers. There are different design considerations and different techniques.

“Scale up or scale out” is a seemingly simple question to ask yourself, but it can lead to some illuminating discussions with your engineering team.

A letter to customers using Rogue Wave ® Stingray ® products
Patrick Leonard, VP Product Strategy & Marketing

As part of our ongoing commitment to the Stingray product, Rogue Wave Software is adding significant new functionality in 2009 and beyond.

Recently, Microsoft has made significant enhancements to the MFC libraries with the release of the MFC Feature Pack, and much of our effort will be addition of support for the MFC Feature Pack.  In addition, we are adding new support for other MFC components as well as features of Windows, Office and .NET.

Key highlights will include:

Support for and ease of migration to MFC Feature Pack
The Microsoft MFC Feature Pack is not built on top of MFC, it is a separate package.  As a result, there is some migration effort for existing MFC and Stingray developers who want to use it directly.  The Stingray Objective ToolkitEx will be designed to not only support the capabilities in the MFC Feature Pack but also to make the migration to this new technology easier than using MFC + MFC Feature Pack alone.

Support for XP/Vista themes
The new Windows Vista look and feel is one of the most popular features in Vista.  Future versions of Stingray Objective Grid and Objective Chart will use new MFC 9 components and support XP/Vista themes and colors.

.NET interoperability
Improved embedding of .NET components (including WPF components) in a Stingray application, and vice-versa (requires mixing managed and unmanaged code in your application).

We will be sending more updates as release dates are available. We appreciate the investment that you have made in Stingray, and invite your comments and suggestions at (sales@roguewave.com).

Best regards,

Patrick

Patrick Leonard
VP, Product Strategy & Marketing
Rogue Wave Software
pleonard@roguewave.com

I meet with a lot of our users in my role at Rogue Wave, and one of the things that I’ve heard from a few people lately is the term “Java envy”.  When I ask what they mean by that, they’re not referring to the language itself.  C++ developers like the control they have over memory usage and predictable performance.  What they’re talking about are the multitude of developer tools that are available for Java development.

Rogue Wave has always strived to be the leader in providing C++ products and tools to make developers more productive.  One of our products, HydraEnterprise, continues that goal.  HydraEnterprise provides the ability to create, orchestrate and deploy services to a runtime.  It can create web services, as well as native C++ and Java services, BPEL, data access and others.  It also comes with some developer tools that make doing all those tasks much easier.  The tools are Eclipse plug-ins that allow you to create services within an easy to use GUI, taking advantage of the editors within Eclipse.  You can create WSDL files, generate service wrappers, orchestrate the workflow between services and deploy to the runtime very quickly.  If you would like to see this demonstrated, we have an online tutorial series where one of our sales engineers will create and deploy a C++ service in under 30 minutes.  Send an email to tutorial@roguewave.com indicating your desire and you will receive an email with the details for the next demonstration.

C++ developers rejoice, as Rogue Wave is still working to make your lives easier.

In the first installment of this post, I discussed the move that all of the major computer hardware vendors have made toward multi-core CPUs, and the resulting Multi-core Dilemma.  I then summarized their strategies in two categories: homogenous and heterogenous.

In Part 2, I’ll talk about pros and cons of each approach and some things to think about as you plan your parallel strategy.

Homogeneous CPU multi-core strategy

- Pros:

• Easier programming environment
• Easier migration of existing code

- Cons:

• Lack of  specialization of hardware to different tasks
• Fewer cores per server today (24 in Intel’s “Dunnington” and 8 cores / 64 threads in Sun’s Niagara 2)

Heterogeneous multi-core strategy (CPU, GPU and more)

- Pros:

• Massive parallelism today
• Specialization of hardware for different tasks.

- Cons:

• Developer productivity - use of the software tools requires special training.
• Portability - software written for GPUs will not run on other GPUs or on CPUs.
• Manageability - multiple GPUs and CPUs in a grid need their work allocated and balanced, and event-based systems need to be supported.

If you are looking to scale an application using GPUs, there’s a lot of horsepower there.  But there is also a learning curve involved in using nVidia’s CUDA and AMD’s Brook+ programming environments.  More on that in a future post.

History

For almost 20 years, Rogue Wave Software has been one of the world’s leading providers of C++ libraries and components. From an early time in our evolution, we have provided the most widely portable C++ standard library available - the “Rogue Wave C++ Standard Library”.

Rogue Wave SourcePro C++ (and its predecessor .h++ products) have supported building with the Rogue Wave C++ Standard Library and the “native” standard libraries (those that ship with each compiler) for years. Two years ago we donated the Rogue Wave C++ Standard Library to the Apache foundation. It is now an open source project known as the Apache C++ Standard Library.

Recent trends

The C++0X standard is one of the biggest things to happen in C++ development in quite a while (that may be the understatement of the day), bringing many exciting new features to the language. Rogue Wave has been active in the development of this new standard. Since most of the changes affect the C++ standard library, this means a heavy investment would be required to update the Apache C++ Standard Library for the new standard.

At the same time, other solid alternatives are available. As the C++ standard library specification became more stable, the API has become very consistent between the Rogue Wave/Apache C++ standard library and native C++ standard libraries. As a result, many people have already moved from our standard library to the native standard libraries.

Realizing that this would inevitably impact our ability to invest in our SourcePro, Hydra and Stingray products, we have determined that the best way for us to support our customers is to focus our effort on our core products and leave standard library development to others.

SourcePro C++ Edition 10 update 1 will be the last release to certify with the Rogue Wave/Apache C++ standard library. A 12 month obsolescence period begins with the shipment of Edition 10 update 1, during which customers use of the Rogue Wave/Apache C++ standard library will fully supported. At the end of this period, we will no longer certify SourcePro with Rogue Wave/Apache C++ standard library and cease development on the Rogue Wave/Apache C++ standard library itself.

Focus on Core Products

Our job at Rogue Wave is to make sure that our SourcePro, Hydra and Stingray customers continue to be successful, and this move is designed to help us to do just that. By dropping support for the Apache C++ standard library we are able to increase our investment in SourcePro. This gives us more time for ports, enhancements, bug fixes, as well as taking advantage of new C++ language features as they become available. I’m confident that this will result in a better overall experience for our customers.

Going forward

Rogue Wave encourages all of our customers to begin using native standard libraries. SourcePro will continue to be certified with the native standard library for each supported compiler. Rogue Wave software is committed to the success of our customers and the SourcePro product. We thank each of you for your business - please feel free to post a response to this blog with any comments you have on how we can improve your experience as a Rogue Wave customer.

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.

By Patrick Leonard, VP Engineering & Product Strategy

Expansion of our Relationship

Rogue Wave and AMD have a long-standing partnership to advance C++ software development on AMD’s Opteron CPU platform. I’m excited that our two companies have recently announced an expansion of that relationship to make it easier for software applications to take advantage of the additional computing power available on multi-core CPUs and on GPUs (graphical processing units).

For several years, increased performance from all hardware vendors has largely come from additional “cores” instead of faster clock speeds. This provided significant additional processing power, but most existing software doesn’t adequately take advantage without significant modification. This is called the “Multi-core Dilemma”.

Challenge and Opportunity

The Multi-core Dilemma is both a challenge and an opportunity that will increase rapidly as the number of cores and threads continues to increase. A typical GPU already has 128 threads. For applications that lend themselves to parallel processing, this can mean a significant gain in throughput.

Although GPUs have the potential for even greater processing power than their CPU counterparts (for certain applications), there are additional challenges as well:
1. Developer productivity - use of the software tools requires special training.
2. Portability - software written for GPUs will not run on other GPUs or on CPUs.

Our partnership is designed to address both of these issues, and to close the gap between hardware and software that has been widening over the past few years.

Although both companies are committed to broadly applicable solutions, our initial focus is on the financial services industry, where much of the activity is already happening.

What are your experiences with multi-core CPU and / or GPU? Please post a response with your thoughts.