VOSibilities

Active Endpoints, in collaboration with fifteen other vendors and enterprises, announces formation of group to promote web services interoperability.

 Ebook: Download (592)

Active Endpoints today announced the Java Advancement Kit, a set of education, training and products that will enable Java developers to take the next step in their professional advancement by quickly and easily using web services to create compelling service orchestrations.

 Active Endpoints Announces the Java Advancement Kit: Download (672)

Please join us for an informative webinar on April 17 entitled BPEL Basics for Java Developers. Register here.

This informative webinar will help you expand your Java knowledge to acquire an understanding of the basics of BPEL. A high-level overview of BPEL and its importance in a web-services environment will be presented, along with a brief discussion of the basic BPEL activities and how they relate to Java concepts. The following topics will be covered:
• Parsing the Language of SOA with Java as a guide
• Breaking out of the VM: evolving from RPC to Web Services
• BPEL Activities – Receive, Reply, Invoke • BPEL Facilities – Fault Handling and Compensation (“Undo”)

We hope you can join us.

A fascinating post on the Inside Architecture blog lambastes SOA tools for creating JaBoWS (just another bunch of web services).

Nick Malik writes:

Don’t get me wrong. I don’t hate tools. For one thing, there are some tools that support Enterprise SOA. Not many, but a few. Those tools understand that Enterprise SOA is not about building one service after another, but building the right services, and building them in a manageable and non-overlapping way.

Nick goes on to say that companies that companies that do not implement a “comprehensive Enterprise SOA transformational program” end up with “tripe.”

Have you ever violently agreed with some one’s conclusions but disagreed as violently with the premise? Well, that’s where we find ourselves after reading Nick’s very passionate (and well-written) post.

In short, when you build a SOA up of piece parts, you would tend to believe that service orchestrations — the actual applications — can be built from piece parts. And they just can’t. What’s good for the architecture isn’t good for the developer.

Developers — especially Java types who are creating web services willy-nilly and then running into a wall trying to use them — need something both familiar and holistic to actually get some value from those web services. They need a visual orchestration system which is complete, standards-based and familiar. Something that masks the complexity of long-running transactions, includes human tasks, eliminates hand-coding of XML, offers discovery of available services and, above all, makes testing and deploying services-based apps easy.

ActiveVOS can do all that, and more. Yet some people call us a “tool.” (I’d prefer SOA development system, but at the end of the day, if you are the tripe-buster, what do you care what people call you?)

Nick is exactly correct that the tools people have been using before VOSs yield little but JaBoWS. As long as developers have to put all the pieces together, you can’t get anything else. But there’s magic in making SOA development integrated and familiar.

Don’t blame the tools. Instead blame those who become captives of their own thinking, by extending the assumptions they made in building their SOA to the development of applications to run in that SOA.