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.

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.

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.

In a recent blog post, Alex Cameron with EDS talks about SOA becoming the dominant architecture for Software Development. I could definitely see how this could be true. It seems software development has progressed and chosen certain styles of programming languages for a reason. As Java and C++ instrumented separate implementation and interfaces, developers realized they could more easily use another developer’s work without having to know what was going on under the covers. Companies and managers saw that they could more efficiently manage and control large projects with various teams interacting with each other. It led to easier to understand software, more productive development teams, and even documenting the software became simpler as the interface was a great guide as to what the component did.

So what is the extension of that? Not only would that developer like to use someone else’s work without knowing anything about it, but they also want to have access to work done on other OSes, on different hardware, in different languages, and all without having to understand the details. So the previous model of finding a .h file or some other class description in the appropriate programming language would be replaced by a search of WSDLs for the functionality needed. No longer would the developer be limited by language, platform, or in some cases, even geography or affiliation.