VOSibilities

For this episode of our podcast, I am very pleased to bring you a video recording made by our own Kim Pease in which she demonstrates ActiveVOS’s capabilities to interact with JMS queues. Kim gives a great overview of what you can do with ActiveVOS, but even more than that, the features she demonstrates make a very subtle but important point: orchestration developers don’t live in a 100% SOAP world.

Many of the services developers need to orchestrate are available via JMS and originate and terminate in common systems like MQ Series and JBoss. We believe it’s very important to be inclusive of these transports and to make sure they are able to participate in a first-class way with SOAP-transported services. In short, being “doctrinaire” about how services should communicate with the orchestration system only serves to impede developers who deal with heterogeneous systems as a daily matter of course. A good example of this pragmatism in ActiveVOS is at about 6:00 into the demo when Kim shows how ActiveVOS will automatically detect an incoming message’s format and reply in kind.

I want to thank you all for the feedback we’ve been receiving about this podcast series. We will continue to post a wide variety of content: demo vignettes (help me persuade Kim and our other engineers to burn the midnight oil to create more by downloading and viewing this episode like crazy), product information, audio podcasts and PDF content. Be sure to subscribe to this feed at http://www.vosibilities.com/category/podcast/feed or in iTunes at http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=274122495.

You may have also noticed that when we have video for the feed, I try to post both a larger .avi and an iPod-formatted .m4v or .mp4. They are always the same content, but the .m4v is usually smaller because it’s reduced in resolution to fit iPods. Please feel free to download either or both. Also, as a convenience who visit the blog instead of subscribing to the podcast feed, the .m4v can be played in a Flash player on the blog just by clicking on the image.

 

 VOSibilities podcast #8- Kim Pease on using JMS with MQ Series and JBoss to orchestrate web services [9:54m]: Play Now | Play in Popup | Download (258)
 VOSibilities podcast #8- Kim Pease on using JMS with MQ Series and JBoss to orchestrate web services [9:54m]: Download (56)

We are pleased to offer our first audio podcast. Until now, we’ve used our podcast feed to offer videos, webinar replays and news about Active Endpoints in PDF form.

Now, we are going to a more “classic” use of our podcast feed by providing audio interviews with the people inside Active Endpoints who are driving our product and market efforts. I hope to offer regular podcasts that span the gamut of topics: from marketing to technology with everything in between.

Enjoy this inaugural episode with Chris Keller, a founder of Active Endpoints, who I stuck in the “Wayback Machine” and asked a couple of tough historical questions. First, “Why BPEL”? And second, “What lead to the requirement for BPEL4People and WS-Human Task”?

 

 VOSibilities podcast #4: Chris Keller on Active Endpoints, BPEL and BPEL4People [14:20m]: Play Now | Play in Popup | Download (132)

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 (223)

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.