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.

Axis2/C is a C based implementation of the Apache Soap engine, and builds on lessons learned from the Java version, Axis2/Java. It is written in C for platform portability, and has a pseudo object-oriented design approach¹. This involves putting operations in the header files and the data in the source files. Also macros are used extensively to hide complexity.

Rogue Wave’s HydraExpress product, on the other hand, is written in native C++, and the code it generates from a WSDL file is also C++. This means that the C++ standard library with its implementations of strings and collection classes are available to the user. HydraExpress is also supported across a wide range of platforms including Windows, Linux and UNIX.

For C++ developers who wish to easily create and deploy Web services, the pseudo object-oriented design approach and C language implementation of Axis2/C can present challenges when starting development. The HydraExpress C++ approach may present a coding style that is more familiar.

The example below is a comparison of the code required to implement a simple “Hello World” service in both Axis2/C and HydraExpress.

Axis2/C

adb_helloResponse_t* axis2_skel_GreetingService_hello(const axutil_env_t *env,
                                                      adb_hello_t* hello)
{
    /* TODO fill this with the necessary business logic */
    adb_helloResponse_t *response;
    axis2_char_t *input_message;
    axis2_char_t *output_message;

    /* Build the response adb */
    response = adb_helloResponse_create(env);
    if (response)
    {
        adb_helloResponse_set_return(response, env, output_message);
    }
    return response;
}

Hydra Express

std::string
GreetingPortTypeImp::hello(rwsf::CallInfo& callInfo,
                           const std::string& hellorequest_in)
{
    return std::string(’Hello from server ‘ + hellorequest_in);
}

References
1. http://wso2.org/library/252

By Patrick Leonard, VP Engineering & Product Strategy

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.