ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: BPEL Process as a POJO
Date Fri, 11 Jan 2008 14:56:21 GMT
On 1/10/08, Fernando Lozano <chopper.jose@gmail.com> wrote:
> Recently we've been studying a change on how we do things around here, and
> this question came up: "Is it possible to have BPEL processes as a POJO
> instead of a Web Service and have it called as regular Java?"
> So it is my duty to investigate and try to find an answer and considering
> your expertise I thought I might ask here and hear what you have to say.

Hi Fernando,

To a certain extent, many WS framework allow you to write a plain Java
interface and generate WS stubs and WSDL description for it.  You can then
use the WSDL to implement the process and have fairly simple Java code
overall.    You can also write your WSDL first, and generate Java-idiomatic
WS stubs for it.  This generally leads to more interoperable web services.

But I think most people would agree that for use-cases where WS
interoperability is not a goal, having to deal with WSDL and XML at all is a
pain.   The long-term plan and ideas that have been discussed within this
project can be grouped under the following categories,

1) A way to write more concise and more dynamic processes while retaining
the general BPEL model (SimPEL)
2) Similarly, more concise syntax for service description (Simple WSDL,
RELAX-NG, REST support)
3) An easily embeddable and lightweight integration layer that offers more
Java-idiomatic service invocation  (Embedded IL)

I think your post is more about #3 above, although I think #1 and possibly
#2 are necessary to make BPEL more accessible and enjoyable to a wider
audience of programmers who don't necessarily want to use heavyweight
development tooling.

If you have ideas and resources to move any of these projects forward, your
help would be most welcome.  More concretely, if you want to get started on
a proof-of-concept for #3, just to collect and post your ideas of what
processes exposed as POJOs could look like on the wiki, please do!  I think
you'll find many interested parties on this mailing-list.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message