Software developers bring SOA apps into cloud computing architectures

Due to rising demand, software architects and developers are currently hard at work bringing SOA apps and ebbs into cloud computing architectures. Unfortunately, early implementers have found some roadblocks, says Jeff Genender, a well-known IT book author and open source consultant. For instance, the difficulty of deploying component updates without rebooting is a big problem. He noted that familiar hot swap capabilities can't be taken for granted up in the cloud; but frequent restarting may defeat the purpose of investing in the cloud at all. SearchSOA recently spoke with Genender to get a handle on this topic.

What does cloud computing do for SOA? It allows for provisioning of services on the fly. So you're able to not only bring up instances of ESB containers and plugging that into service-oriented architecture; but you're also able to provision the actual services and bring them up or down and be able to federate your services so you can earmark certain instances inside the cloud to only execute certain kinds of services. What are the biggest...

challenges with getting an ESB to work with the cloud? The challenges are the ability to hot deploy without having to restart – to both deploy and un-deploy. To be able to turn instances on and off and have them instantly be able to communicate as one big solid bus. What's so special about ServiceMix4? What does it do? One of the things that ServiceMix4 does is the ability to have OSGi bundles that makes it so there's no real impact on the class loaders. It makes it so as you deploy and un-deploy it makes it so the need to restart your instances is diminished.

Service Mix was basically a [right] of the Java Business Integration (JBI) for Java and open source implementation. It's an apache-based product. It was mainly focused on JBI implementation but as time went on, folks kind of understood that there's some acceptance and adoption of JBI and some not. Some like to send messages without having the overhead of JBI implementations. So ServiceMix 4 came out with the lessons learned from ServiceMix3, which was the ability to have truly hot-deployable modules that apply to a certain standard, so OSGi was picked for that. And also the ability to do messaging and routing without the necessity to use JBI components.

Now it is backwards compatible. It does allow you to use the JBI implementation or you can go direct and just use Camel in and of itself as a router to rout your messages. Why are developers and architects growing more interested in OSGi?
Because Java was originally put together to have JAR files that are deployed and un-deployed. The idea was to make these web applications hot deployable and un-deployable without impact on Java EE. The problem ended up being that we noticed that it wasn't really clean, that class loaders effected memory. There was this big push to modularize dependencies between different modules, give them lifecycles for when they stop, when they start – and mace it so it truly is a secure way to deploy a component or an application that will not affect the container, and would not have memory and class loading impacts. And it was also a way to implement dependency management between the different modules. So how mature is OSGi right now?
I think its adoption at this stage is becoming quite the standards. Eclipse is nearly completely based on that from a plug-in perspective. More and more containers are utilizing it. We've got the new Glassfish coming up that's going to have OSGi, Geronimo3 looks like it's going to be OSGi based. You've also got the Spring OSGi containers. It's really becoming a standard across the board for being able to hot deploy and un-deploy applications within some form of container whether it be an IDE or a Java EE server.

I think that it's certainly on its way. It's certainly matured from where it's been. It certainly has a ways to go. It would be really nice if there were more mechanisms to handle dependency management so that there's not just simple failure; where if it needs a certain dependency it would just be able to go out and grab it. But it's certainly matured, and I think it's well on its way to becoming a clear standard.

Genender will be presenting at The ServerSide Java Symposium this March. Genender is a member of the JSR-316 Java EE6 expert group committee, and author of Professional Apache Tomcat 6, Professional Apache Geronimo, and Enterprise Java Servlets.

Dig deeper on Cloud-Grid computing and virtualization for SOA

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close