VOSibilities

I’m pleased that my recent disagreement with JP Morgenthal was noticed by Joe McKendrick, on his Service Oriented blog, and by Loraine Lawson at ITBusinessEdge. Now, having set the record straight, we can step back a little and start a more general discussion about SCA and why it’s a powerful new approach for developing applications. Loraine made a few comments in particular that got me thinking more about the value of SCA to a chief architect who is “prioritizing and rationalizing applications from an enterprise perspective.”

Once this architect has prioritized the needs of IT for the enterprise, it is critical that the architect’s development team has the right “tools” to update or create the applications that will meet those enterprise priorities. The development team also wants to improve its ability to maintain the application in the long run. I put the word “tools” in quotes in the previous sentence to emphasize the fact that I am using the word in its most general form. Your programming language is a tool. The design patterns you follow are tools. And, of course, the middleware infrastructure you use is a tool. J.P. is just wrong to assert that SCA will lock you into dependency on a vendor. There is no reason that middleware has to lock you in to a vendor any more than using a programming language locks you into a vendor, but that is only true if the middleware uses…

standards (and the right standards at that). If SCA were just some vendor’s tool that was promising great things, J.P. and everyone else would be right to be skeptical. But it isn’t proprietary, it’s a standard.

There are a few important reasons why this is important. It is always difficult to hire people who are skilled in a vendor’s proprietary technology and any application that depends on the technology is always at risk, since the vendor may choose to “improve” the technology in a direction that is retrograde for you. Or, the vendor could possibly abandon it altogether.

A good middleware standard is like a high-level language. It raises the level of abstraction that developers work in, so they can think about the actual problem being solved instead of fiddling with bits – or SOAP headers.  There are three recent standards that do exactly this: BPEL, BPMN and SCA.  BPEL is a language that is specifically designed around creating and using services, so it is also inherently middleware. Then there is BPMN, which standardizes the notation — the look of the business process on the design canvas — so that developers and non-developers alike can share an understanding of what is going on. And finally there is SCA, which allows developers to create, wire, package and deploy services without having to sweat the details of the numerous WS-* standards for every service that is created or used.  It, like high-level languages, raises the level of abstraction without significantly constraining what a developer can accomplish.

Forcing a development team to avoid recent advances in middleware today would be like having a manager in the 1970’s forcing their developers to program in assembler due to a mistrust of languages like FORTRAN. Productivity would suffer.

Yesterday (July 22), Red Hat announced its JBoss BPEL server, available via an open-source project called Riftsaw.

As you can imagine, the whole team at Active Endpoints was interested in the announcement because Active Endpoints is a leader in the BPEL standards effort, ActiveVOS processes are executed as BPEL  (but ActiveVOS  is most emphatically not “just a BPEL engine”) and the new project will create more interest in next-generation application development.

I wish you could be party to the intense discussions the announcement of the JBoss BPEL server kicked off inside our company. One the one hand, we note with pleasure the validation of BPEL that a new JBoss BPEL server signals to developers. On the other hand, we worry that what we saw (or should I say, ” what we riftsaw” ) yesterday will be “good enough” for many developers who are new to services-based development and who don’t realize how rich services-based BPM systems have become. In short, we welcome the JBoss BPEL server to the party, but we want to make sure developers understand there’s no reason to set the clock back with systems that deliver elementary tooling, manual command-line deployment, no operational control and hand-editing of XML files. We want to draw a bright line between an integrated, BPEL-based BPMS that development teams love to use and individual technologies that must be pieced together using Notepad++, soapUI, the command line and ant scripts.

Bear with me a minute as we step back and think about where BPEL came from, where it is today and why the JBoss BPEL server is a step back from several years of advancement in the BPM and BPEL world.

First, why even have something like BPEL? Industry standards aren’t just “whipped up” on a collective industry whim, because getting a standard specified and approved is an arduous process. (Just ask Michael Rowley, who labors with other vendors to keep the BPEL and BPEL4People standards moving forward.) To overcome that inertia and make competitors agree, there must be both a pressing need and a general consensus that something has to be done. The shift to services-based development was the pressing need, and Active Endpoints, Oracle, IBM, SAP and others helped create the general consensus. The result? BPEL: a language designed specifically to do what Java, C++ and C# natively can’t: orchestrate services.

But a standard is just that: a specification. To make the standard into a product that developers will love using is a big job, and it’s how vendors approach that product development effort that differentiates their products. The differences between the “raw” implementation of a standard and a fully-integrated product is what makes competitive vendors willing to agree to a standard in the first place. They hope to benefit by delivering complete solutions based on the standard…they differentiate by combining the standard with other features and capabilities to develop whole products that developers will enjoy using because those products are easy, integrated, complete and fun.

Now I believe (and I may upset some folks with this assertion) that the BPEL effort, noble as it is to introduce a purpose-built language for service orchestration, originally shot itself in the foot because it didn’t specify a way to visually design BPEL and because, until BPEL4People, there was no way to integrate human and automated tasks in processes in  a standardized way. Both issues have been corrected, but BPEL has had trouble shaking the reputation of being hard to develop and deploy.

We think the JBoss BPEL server is likely to resurrect that misperception because it lacks advanced tooling and it has not implemented BPEL4People. We fear that large numbers of developers will experiment with the JBoss BPEL server, decide that it’s either too complex, or perversely, “acceptable” because they like elemental tooling and never experience what a modern BPMS with a superior development and deployment environment can deliver.

I want to give you just one example contrasting a “raw” BPEL server and a complete development environment based on BPEL. BPEL has core and very confusing concepts called partner link types and partner links. These are powerful concepts but not obvious, especially to developers new to services. If you are a services guru, you can understand it easily. If you are like many developers, the explanation is likely to give you a headache and make you swear off BPEL. But there’s no reason to expose the concept of BPEL partner links to the vast majority of process developers.

So, in ActiveVOS 6, we introduced the concept of the Participant’s View, pictured here:

In ActiveVOS, we know BPEL so you don’t have to. Once you’ve imported the WSDLs, we can automatically set up the partner links and partner link types (e.g., upstream and downstream “participants”) in a handy graphical view. You simply drag them onto the canvas, and voila!, instant creation of the correct partner links and partner link types. Contrast ActiveVOS with the recorded July 22 demo of the JBoss BPEL server, which demonstrates editing partner links with Notepad++.

We think we know which kind of development system developers prefer. (And by the way, if you really have to or want to edit the BPEL partner link types in ActiveVOS, be our guest. What we produce automatically and graphically is 100% pure BPEL…just the way you like it.)

This is just one example of the difference between a fully-developed, mature, standards-based BPMS the entire development team can use and “raw” technology in the form of an open source  project. We urge developers to look beyond the headlines of “standards” and “projects” to complete products that are rigorously based on standards but which also make development using those standards simple and quick.

Copied below is the text of an email we sent today to more than 30,000 developers in the US. We are in a unique position to see what the rate of adoption of modern development tools is. And what we’ve seen is so strong a trend, we simply had to go public with what we’ve learned. As always, we welcome any comments or feedback, either here on our blog or via email to editor@activevos.com.

Attention US developers: Active Endpoints has a wake-up call for you

Dear Developer,

We are emailing you because we are concerned about you.  We’ve learned something about the state of middleware technology in the US, its impact on outsourcing and US business competitiveness that we felt strongly we should share with you.

Since early March, we have been offering downloads of our new ActiveVOS visual orchestration system at www.activevos.com. With ActiveVOS, you can automate, control, adapt and manage your services-based applications in ways you never dreamed were possible. And, you do it in a 100%-standards based environment, at breakthrough pricing.

As you might imagine, we watch our download statistics very carefully…sometime hourly. We expected to have downloads from all over the world, but the shocking truth is that a majority of our downloads are coming from outside the US, especially from India and China. A conversation I had with a marketing director at a major open-source ESB provider confirmed that company is seeing fully half of its downloads from India and China.

At first, we couldn’t believe it. And we were surprised, because the US market for app dev products is several orders of magnitude larger than in these developing markets. Then, we started asking ourselves questions like “Why is this so pronounced a trend?” And “what do these developers, business analysts and companies know that US enterprises don’t?”

The answers are clear. US companies have become too caught up in the complexity of their current systems…too content to be dictated to by proprietary middleware vendors…too comfortable with their status quo. Meanwhile, companies without legacy issues – and without the temptation to use those issues as an excuse for stasis – adopt the most effective and modern middleware technologies rapidly.

Is it any wonder, then, that US developers are increasingly frustrated by the slow pace of change, the threat to their jobs, and the technical and political paralysis created by so-called enterprise architectures?

Clearly, we hope you will be the agent for change in your company and download ActiveVOS at www.activevos.com. We hope you will take advantage of our education center to update your skills. We hope you will join the hundreds of developers who have watched the replay of webinar we hosted called “BPEL for Java Developers.” (You can find it on our blog at www.vosibilities.com or in our podcast feed in the iTunes Store; search for “VOSibilities.”)

But mostly, we hope you will carefully consider the fact that the status quo in application development in your company is a very dangerous proposition. No matter how daunting change may seem, it’s better than the alternative: a world in which your company and you personally have been eclipsed by external competitors.

 

Thank you.

 

Alex Neihaus
VP Marketing
Active Endpoints, Inc.
editor@activevos.com

Today, we are very excited to announce ActiveVOS 5.0, the industry’s first visual orchestration system. You can read the details in the press release below. (And starting Wednesday, March 5, 2008, you can actually request a trial.)

As they say in the TV commercials, this changes everything about SOA. From capabilities, to pricing, to performance, to support for standards, ActiveVOS changes it all…for the better.

We hope you will become part of the revolution.

 Active Endpoints ships ActiveVOS 5.0: Download (731)

Please forgive me. This post strains two metaphors and doesn’t do it very artfully. One, the camera obscura, represents, literally, the “dark room” in which many developers find themselves when working with a non-standards-based SOA development platform. The second, “through a glass darkly” represents the transition, indeed, the revolution, that developers need to accept in order to get SOA applications widely deployed.

Because this metaphor exists only in my head, I’ll spare you the rest of this post if you can’t figure out what I am talking about. Here’s the bottom line: ActiveVOS is the answer. Read no further, just download the product and see for yourself.

OK, back to my strained, mixed metaphors. The camera obsucra projects the application you’re trying to create from the other side of the wall. Building that application with proprietary tools is the equivalent of getting there “darkly.”

What I am trying to say is there are three things about building SOA applications you should always keep in mind:

• If it ain’t standards-based, just don’t do it. For those of you who have wedded yourselves to Oracle or whatever-your-favorite-proprietary-vendor-stack-is, you are trying to trace the image on the wall using doomed technology. (Now that was a good use of the camera obscura metaphor, don’t you think?)
• You need the complete package. Piecing stuff together yourself is the ultimate in getting there with muck all over you. It will take longer, cost more and be less flexible. Period, end of story, full stop.
• You gotta reuse what you already have. Nothing is worse than being told you can’t start with at least a trace of the image on the wall. Maybe you’ve got lots of what we used to call “legacy mainframe” stuff (which we all know is running the business). Maybe you want to use Java. Maybe you need to include human workflow. Whatever the situation, having to start over just isn’t an option.

Mercifully, I’m gonna stop here. It may be that you have no idea what I am talking about. But I don’t think that’s the case. More likely, you are mounting a defense in your head of why you cannot “abandon” the path to SOA-based applications you’re on.

C’mon, just between you and yourself, aren’t you willing to admit there’s a better way? Visual orchestration systems, and ActiveVOS in particular, are the digital camera to proprietary systems’ camera obscura.

Active Endpoints to Drive Mass Adoption of Services-based Applications

 Active Endpoints to Drive Mass Adoption of Services-based Applications: Download (648)