really glad you replied, I thought I was being ignored for being to adventurous in my thinking... in general I think that having something like BPEL in a system is a great thing, with all the theory behind workflows, but Im trying to imagine it in the context of millions of hits, and really easy scaling... with that said something made me think more and more about how easy/difficult it would be to have the same semantics implemented in say Erlang... I hope I didnt insult people here, but Erlang is nativelly supporting some of the thigns that I see Jacob talking about. Its a really neat/simple little language with a phenomenal VM that takes care of scalability like a charm.
Im not enterprise house so sticking to BPEL as defined by the standards is not something that is a must, its just the long running stuff that attracts me, and the idea of having non-tech people design worfklows in BPMN... Been reading about ProtoBuffers from Google too, and their concern with performance is exactly what I have in mind as well... In the process of writing a small Scala2WSDL tool, and thats almost done, so I guess Im cool with WSDL ;), XPath is baked into the scala.xml package, so Im cool with that too... Im blabbing here, Im sorry, but really minimizing the amount of stuff thats in the runtime is what Im thinking about, and coding something up in Erlang is seeming like a more and more of a good idea... we'll see, I'll keep you posted. ps. Im still going to research the IL further. a wild thought - replicating the Jacob API in Erlang and then pluging that into the rest of ODE? thanks On Mon, Aug 4, 2008 at 1:33 AM, Paul Brown <[EMAIL PROTECTED]> wrote: > > On Aug 1, 2008, at 9:08 AM, Ivan Trajkovic wrote: > >> on a side note, it would be cool if the interface definition for the >> processes was abstracted into its own layer, so that other IDL's (besides >> WSDL) could be used (WADL, Google protocol buffers - although Im still not >> that familiar with GPB's as they might be only a simple data message >> definitonl language[perhaps can be hacked into definiting method >> signatures >> as well])... either way, it would seem powerful if ODE was capable to >> accomodate other IDL's, its use would increase drastically... I understand >> this probably a non-trivial amount of work. >> > > Other IDLs is a big deal, depending on how you look at it, since the > combination of XML, WSDL, and XPath (1.0 or 2.0) is deeply ingrained in the > BPEL language. (File that under "it seemed like a good idea at the > time"...) It's certainly conceivable that people would be interested in > using something like Java for the IDL with POJOs, no IDL with > JSON/Javascript, etc. The good thing about the WSDL/XML/XPath stack is that > it's friendly with the philosophies of the engine and the design of BPEL, > and it's purely a question of effort and inclination for someone to have a > version of ODE that would support their chosen combination of IDL, > expression language, and message format so long as the overall flavor of the > implementation didn't change too much. > > Now, that said, some of this is purely a matter of the level of indirection > in your thinking, and this is why the integration layer (IL) that Matthieu > pointed you at is probably the right place to start. For the engine to use > XML internally along with all of the usual trappings (WSDL, XSLT, XPath, > etc.), you could feed it about anything — JSON, EDI of various flavors, a > binary wire format, etc. — which would be dealt with as XML within the > confines of the engine and converted to and from XML by the IL. > > Given that you seen to have a taste for the wind in your hair and bugs in > your teeth (a good thing!), you should also take a look at the JaCOb actor > layer that underlies the ODE BPEL implementation. > > -- Paul
