Integrated Infrastructure Blog

Open Source Software Powers the Biggest Physics Project in History

Today Progress Software announced that the European Organization for Nuclear Research (CERN*) is using Progress® FUSE™, to run its operational grid activities of the Large Hadron Collider (LHC) re-launch which happened this month. FUSE is an open source product line based on several Apache projects for which IONA (acquired by Progress in June 2008) provided leadership and Progress today continues to be a significant contributor. There are many skeptics that believe open source software isn’t meant for large-scale projects but CERN has proven that wrong. Not only has FUSE will underpin all grid monitoring systems used in CERN’s quest to find the Higgs Boson—known as 'The God Particle', but CERN welcomes the opportunity to contribute back to the open source project and deploy it freely across all their sites.

James Casey, Technical Architect at CERN, sites “We needed to find a partner that could help us bring agility and reliability to our IT infrastructure.” He added, “We have a pipeline of projects that we need to deliver over the coming years, so this first step lays the foundation for change.”

In addition to using FUSE, CERN also deployed Progress® SonicMQ® to form the communications backbone of its Technical Infrastructure Monitoring (TIM) system, designed to alert researchers in the event of an emergency. The use of open and “closed” source software creates a true open integration environment that re-enforces the fact that every organization has the power to choose the solutions that best fit their integrated infrastructure requirements.

RE: The wrong marketing for open source

Matt Asay makes a good point in his article on open source marketing, that people generally choose to use open source software because it is cost effective, not because it is “flexible”.

Put another way, “free as in beer” trumps “free as in speech” as a motivator for people making the choice to use open source. I think that is obvious. On the other hand, I think that it is so obvious that the premise of the article that open source should be marketed on the basis of low cost over freedom of choice is wrong. I think the market widely assumes that open source is “free as in beer” so you get the benefit of that perception just by being open source in the first place.

That said, he does refer to the importance of “low cost utility.” It isn’t good enough that Linux or MySQL or ServiceMix ESB is open source, (i.e. perceived to be “free as in beer”). It also has to be good enough to be useful in helping someone solve a real problem. In other words, the beer has to be drinkable or doesn’t matter that it’s free.

We, Progress Software, are also seeing companies begin to recognize that adopting open source isn’t entirely free (as in beer). They will be more successful getting the utility from the software if they invest in developing the skills to use the software properly and have the backing of a company to support them in that effort. To take the beer analogy a bit further, (perhaps too far?), renting a mug is better than drinking the beer out of your hands.

From an open source marketing perspective, what we need to do is let people know that the beer tastes good and explain how much better the experience will be drinking it from a mug. We don’t need to spend a lot of time explaining why it’s a good thing that the beer is free.

Who’s in Charge of the Architecture? You Are.

In Replacing Large Applications – Who’s in Charge?, Kathy Harris at Gartner writes:

"Most of the organizations have no real architectural vision for their system. The result is that they are essentially allowing the vendor to establish their architecture. This may be ok in the long run, but for many organizations, it is a de facto decision rather than an active choice."

While many vendors have the expertise to make the right recommendations for their portion of a solution, things become much more complicated when you start integrating their applications with others. Complexity increases exponentially when you consider the changes being made by other departments, in other locations, and by your partners.

The complete picture can be daunting. Great enterprise architects understand that you don’t need an exact schematic of how infrastructure will evolve over the lifetime of the business. Rather, you need to take proactive steps to incorporate flexibility into your architecture. And the best way to do this is to partner with vendors that adopt Open Integration principles to ensure that your architecture can grow to support the business as it evolves.

If you’re concerned that your vendor is prescribing your architecture for you, consider these three Open Integration requirements:

1. Make sure your vendor supports open standards. This means that they support de facto standards as well as those specific to your industry. More importantly, they should also be involved in defining emerging standards, to ensure future compatibility. If your vendor supports open standards, you have a better chance of adapting to change.
2. Develop an open architecture. Look for solutions that are modular in nature and allow you to mix and match functionality to meet your needs, while only paying for what you use.
3. If possible, leverage open source. By using open source, you reduce your price of admission to mission-critical infrastructure. More importantly, you have direct access to the source code and those who wrote it.

Organizations need to take an active role in defining architecture. All three Open Integration principles allow you to actively choose what’s right for your business, instead of being at the mercy of others and hoping it will all work out in the long run.

Simple SOA. Not-so-simple SOA.

Open Source SOA has arrived! On a single day we have one platform announce that they have simplified basic SOA, and another has announced that SOA is never simple - and if it is simple, just use web services. The question is... is there really a simple SOA and a not-so-simple SOA?

As I look at it, there is a very fine line between simple SOA and the more complex ones that require an enterprise service bus (ESB). Lines are blurred today. Now, ESB itself can be in a single container or more massively distributed ESBs with a strong messaging backbone (like Sonic ESB). But messaging backbone or not is more about the underlying integration infrastructure. So, what does it mean for the application itself? Is the model/paradigm different for the two cases? This is what gets lost out in the melee - the application models and the underlying infrastructure are quite decoupled. From an application standpoint many of the ESB mediation requirements may always be needed functionally. Can one access services without getting the data in the right format? To get it in the right format, won't we need data transformation? And security is a given in all cases. Sometimes one can look at business rules based routing to services. All of these regardless of whether it is a simple SOA or not-so-simple (more distributed multi-data-center) SOA. 

This (common treatment of all SOA use cases regardless of complexity) is very evident with the way our open source platform, FUSE, works because it has an embeddable transport layer. One could use the containers with or without Active MQ. But with or without distribution, the same functionality is available. Simple SOA? Or not?

Actional for IONA Orbix & DB

I've been on the road since the end of May and I have also moved, so needless to say, I'm behind on my blogging and tweeting responsibilities. I mean, you know you're busy when you don't have time to tweet!

My colleagues have been out there though, doing some great things. We've got some early trials going on with Actional being evaluated at a few IONA Orbix (CORBA) customers. Since the team has tweeted this, I thought I'd blog about it!

As Frank Lynch said, "CORBA users will be mighty pleased to have Actional visibility, an no performance penalty to boot." Yep, couldn't a' said it better myself.

Why is Actional/Orbix integration important?

1. It demonstrates a key differentiator between Actional and all other solutions out there... we're not designed specifically for web services. Never were. Extending Actional beyond web services started in late 2003, and continues with the work we're doing with the Orbix team.
   
2. CORBA customers are "interesting" in that they are typical enterprise class deployments. They have high message rates, are deployed in critical infrastructure, and are sophisticated deployments due to their maturity. Right in Actional's sweet spot.
   
3. In this down economy, Progress has a key advantage over our smaller competitors, so much so that it's hard to actually view these customers as competitors. Where these small guys have to go and develop new customer relationships, we can continue to delight our existing customer base (in over 100 countries) with innovative integrations between the products in the Progress portfolio. This continued innovation enables us to drive market adoption while delivering products that meet real enterprise customer needs.

On that last point, I've got a bit of a new role here. Or, better said, my role is being further formalized as Actional Product Evangelist. I'm very pleased to have the responsibility for socially-marketing some of the new integrations we are delivering to market. In particular, those integrations between products in the Progress portfolio and Actional, and between Actional and some partners. I'm hoping I can have a real impact with this formalization to my role, as well as some fun introducing Actional to some new technologies.

That said, my initial focus is going to be on IONA's Orbix, Progress OpenEdge, and Sun Glassfish. Glassfish support has been released, and both IONA and OpenEdge are in early trials (pre-beta). As I get organized around communicating these solutions, feel free to drop me a line with questions if you are interested in seeing what we've got!

Any existing Orbix customers interested in the Actional integration should contact your sales rep... or me. You're required to have Orbix 6 or later for Java (for now... we're working on the C++ and Java/C++ for Orbix 3, but they're not ready to trial yet).

PS Why not follow Maneesh Sahu (Sr. Solution Architect, Partners), Dion Picco (Engineering) , Frank Lynch (Sr. Solution Architect, East), or Marcelo Jabali (Sr. Solution Architect, West)?

Do we really need this complexity?

My first post on the Progress SOA Blog! This gives me jitters... All the writing till now was somehow different. There was a carefree attitude to that writing. When I wrote my book (nearly 40% of the book on SOA approach to Integration), or when I write my personal blog posts, I never had to worry about the impact. Now as informal as this may be, at the end of the day it does have a non-personal tone. Even so, I am excited about this. :-)

My views essentially are reflections on the software services and SI ecosystem and what/how they use technologies in the integration solutions space. Lately, I have been also quite caught by the SaaS/PaaS promise in the SOA context - even if I am quite skeptical about the hyped up value.

Recently, I was speaking on this topic at the IndicThreads conference on Java at Pune. I included a slide on the complexity of SOA. While in my flow I was using it to talk about some of the SOA enablers in our SOA portfolio in simplifying this complexity, the presentation and some following questions triggered a thought... How much of this does the industry actually need? Aren’t these more of a fringe scenario that needs all of this? Isn’t the REST vs. SOAP argument a good case in point? 80+% of the world needs only basic remote service mechanism. While REST more than suffices here, this basic need from the world is but just a small part of SOAP! So, who needs the rest?

The simplicity of REST is stark - at least when compared to the extremely unwieldy SOAP and its numerous accompanying specifications. And it is further compounded by all the WS* standards. Making things worse are frameworks for frameworks such as WS-Policy. WS-policy is a framework that layers on SOAP. And there are other standards that use WS-Policy as the basis for definition. In effect, we have XML over HTTP, on which is defined the SOAP standard, on SOA is the WS-Policy. And on WS-Policy are standards such as WS-S & WS-T. Phew!

Now compare this with REST - that actually has no other specification other than HTTP itself! Granted, this seriously limits what we can do with REST. But lets accept it - the world needs mostly ONLY the likes of just REST and only a very small fraction needs the multiple layers of specifications such as SOAP! Even in the SOAP land this is very well captured in how AXIS evolved - trying to keep pace with the rather haphazard offshoots of SOAP. And now there is CXF whose basic premise is to simplify SOAP and Web Services. From the word go, it has embraced the simplicity and is also trying to be more about services and less about SOAP. In the spirit of the latter, CXF also supports REST right off the bat.

I see 2009 as year where this simplicity is bound to get consolidated. The more simpler and easier the SOA framework becomes, the more it will get accepted. FUSE open sources SOA framework will be one very serious contender in this space. Functionally as complete as any other SOA solution, yet lean and mean with a good set of tools. Watch out for more in the months to come.