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

To understand what a technology does and why someone might want to use it, I think it’s helpful to compare what life was like before and after using it.

Like when Blackberry came out with their first full PDA version.  My “day in the life” before that was that I had a paper planner that I used to track my contacts, to-dos and notes.  It was bulky and I frequently didn’t have what i needed when I needed it.  If I lost it I was S.O.L.  My “day in the life after” is that I have my personal data with me all the time and it’s always backed up so I don’t have to worry about losing it.

People often ask me what Hydra is, and I say something like “it’s an integrated development and deployment framework for C++ and Java services.”  This is accurate, but doesn’t really give a good picture (and I’m a visual guy, I like pictures).

So here is my “day in the life” from a software engineer or architect’s perspective - before and after Hydra:

Before Hydra:

• I have an application that has been around for a while, written mostly in C++ code.  I prefer the power of the language and I don’t want to rewrite it, but it takes a lot more development time to maintain and enhance this application than if it were written in another language like Java. 

• The development team mostly uses command shell editors and a custom build environment, which is a steep learning curve and productivity sink for the more junior engineers.

• Our deployment environment works, but we have had to cobble together different software, some commercial and some open source, to make it all work.  It’s hard to maintain and upgrade and I’d like to simplify the environment and reduce the number of vendors that I work with.

After Hydra:

• Once the development team starting using the Hydra IDE in Eclipse, they became much more productive both with C++ and Java code and it’s all in one tool.  The automatic code generation saves a lot of the ‘grunt work’ and it’s easier to debug, test and redeploy, shortening our dev cycles - this is huge in supporting our move to Agile Methodology. 

• The Hydra runtime hosts both C++ and Java services in the same process so I don’t have to pay the performance cost of web services when they’re on the same server.  I can use BPEL to orchestrate the services, but I don’t have to.  Plus, I know that the whole thing is deployed to a scalable service grid that I can reconfigure as my requirements change.

• In addition, it’s a single, integrated environment.  I can add other components if I want to, and the architecture is much cleaner and easier to maintain and extend.  It’s based on web services and SOA standards (WSDL, SCA, etc.) so I have some protection from vendor lock-in.  And I’m closer to having “one throat to choke” with my vendor when I need something.

In all, we’ve reduced our development effort, so we can do more with less and get releases out faster.  This has saved the company money and makes our team look better.

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.

Avik Sengupta from Lab49 wrote an interesting Guest View in the latest SDTimes about recent additions to Java to improve support for programming to multi-core hardware. 

When I started talking about the Multi-core Dilemma a few years ago the conventional wisdom in the Java community still held that we wouldn’t have to do anything different  - that Java would take care of it for us.  I even touched off a nice little flame war with a posting on The Server Side…

As Avik points out, Java does provide a powerful threading model that helps with multi-core, “but in practice it may not be so easy.“  With the addition of the concurrency package and the new fork/join, the tools for parallelism in Java are greatly improved.

These capabilities in Java, as well as new primitives and tools being added to C++ and other languages are geared at improving the realm of traditional multi-threaded programming for data and task parallelism.  But parallelism at a higher level of granularity - the business process level - is becoming more commonly used.  Business Process Parallelism is a technique that runs multiple instances of a business process, typically implemented inside of a service. This has multiple advantages, which I will cover in a subsequent post.

If performance and throughput are important for your application, consider where business process parallelism may be used in addition to data parallelism alone.

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.

By Patrick Leonard, VP Engineering & Product Strategy

All of the major computer hardware vendors have been moving to multi-core CPUs for several years now, creating the situation that we refer to as the Multi-core Dilemma, which I have written about for several years. Recently, more choices for parallel hardware have become available for enterprise applications.  This will lead to some great opportunities but will also require tricky decisions of software development organizations.

Some of the new multi-core hardware will look more homogeneous, like a group of CPUs. Some of the new multi-core hardware will start to look more heterogeneous, like a CPU surrounded by different specialized cores like GPUs (graphical processing units) and others. Both approaches are going to benefit the industry on the whole, but there are pros and cons for each that should be factored into your software development planning.  This is my breakdown of the hardware vendors’ strategy.

Intel and Sun are pursuing the homogeneous CPU multi-core strategy:

• Intel’s Larrabee project is a many-core CPU strategy that they argue will reduce (or eliminate) the need to use separate GPUs and other accelerators for general-purpose computing, although it seems likely that it could bear some similarities to GPUs in the areas of floating point and vector operations.  One of the main advantages of this approach is that it leverages the existing X86 instruction set.  Not everyone loves the X86 instruction set, but there are certainly huge benefits to keeping the existing toolchains (compilers, debuggers, profilers) that are already in place.  At Rogue Wave, we have tested multi-core Xeon systems with our Hydra product and see very good scalability with this approach for common business applications.
• Sun recently released Niagara2, their follow up to the industry-leading Niagara multi-core server.

IBM, AMD and nVidia are taking the heterogeneous approach:

• AMD, with their purchase of ATI, added GPU hardware to their offering, and has put “stream computing” and “accelerated computing” (formerly known as “Fusion”) at the center of their strategy, and has partnered with Rogue Wave as part of this strategy.  The vision here is basically fusion of CPU and specialized “accelerators” so that the hardware is more tuned to different use cases.  For example, CPUs are great at time slicing and scheduling, while GPUs are great at processing math in parallel.  AMD recently made a public embrace of the nascent OpenCL standard as a programming model for GPU.
• IBM, in partnership with Sony and Toshiba, has brought the CellBE processor to market.  The basic idea here is similar to AMD’s accelerated computing: specialized hardware tuned to different use cases all on a single chip.
• nVidia is focused on the GPU.  Focus has a lot of advantages; nVidia is ahead of AMD in getting GPU into the mainstream market (although this is still very early stage) and has a more robust API and tool environment with CUDA.  Many people in both industry and academic areas have reported significant throughput increases using nVidia GPUs for complex compute-intensive problems that are capable of running in a massively parallel environment. Rogue Wave is also working closely with nVidia and we have seen excellent performance using their hardware for compute-intensive parallel problems.

All of these strategies are pursuing a similar goal: increased throughput through parallel hardware.  All of them will require changes to existing software to take advantage of this increased compute power.  All of them will also require software developers to think differently about how they design software in the future.