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.
On Fri, Aug 1, 2008 at 12:02 PM, Ivan Trajkovic <[EMAIL PROTECTED]>wrote: > funny how Im sending cries out for help at the same time as the help is on > its way ;) > thanks. this gives me a lot more info to investigate, and reaffirms my > decision to go forward with ODE. > I have so many questions in my head buzzing right now, mostly to do with > process-to-service > communication... but Im betting the API signatures would answer some of > them. > org/apache/ode/bpel/iapi/<http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X/bpel-api/src/main/java/org/apache/ode/bpel/iapi/>is > still the best place to look for those? > Im mainly concerned with efficiency and trying to avoid an unnecessary > copying... but I should investigate more so I can ask more speicfic > questions, before my messages turn into a whole bunch of super-high level > questions that would take hours to answer. > > thanks :) > > > On Fri, Aug 1, 2008 at 11:17 AM, Matthieu Riou <[EMAIL PROTECTED]>wrote: > >> On Fri, Aug 1, 2008 at 8:09 AM, Ivan Trajkovic <[EMAIL PROTECTED] >> >wrote: >> >> > I understand that the questions here are probably way confused. I would >> > really appreciate it if someone just quickly answered them so that I at >> > least know which direction to move in. If I could read up on it >> someplace I >> > would, but I've been out of luck finding a clear source. >> > >> >> Time difference. We're just waking up here :) >> >> >> > >> > thank you >> > humble newbie >> > >> > On Thu, Jul 31, 2008 at 10:20 PM, Ivan Trajkovic <[EMAIL PROTECTED] >> > >wrote: >> > >> > > thanks guys, I'll look into it >> > > just to check, the IL allows me to expose POJO's directly to the >> > workflows >> > > so that I can orchestrate them knowing that no SOAP exchanges will >> > happen? >> > > that is my goal, to know that the worfklow is executed in-process >> without >> > OS >> > > calls for networking (there's a possibility that thats a dump >> statement >> > > since WSDL is used to define services and there might not be any >> option >> > to >> > > have methods exposed "by default" without WSDL's being required). I >> > > understand that its a basic question, but I just want to make sure. I >> > just >> > > realized that IL might be API's for providing core internal services >> to >> > the >> > > ODE engine that are needed for its internal functioning, and not >> exposed >> > to >> > > third-party processes... >> > > thank you for the prompt responses and for somewhat confusing set of >> > > questions >> > > >> > > Ivan >> > > >> > > >> > > On Thu, Jul 31, 2008 at 10:11 PM, Matthieu Riou < >> [EMAIL PROTECTED] >> > >wrote: >> > > >> > >> On Thu, Jul 31, 2008 at 6:51 PM, Alex Boisvert <[EMAIL PROTECTED] >> > >> > >> wrote: >> > >> >> > >> > Hi Ivan, >> > >> > >> > >> > A good place to start, if you haven't looked yet, is to browse the >> > >> > Integration Layer API, >> > >> > >> > >> > >> > >> >> > >> http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ >> > >> > >> > >> > or in the trunk where we've made some refactoring for better >> > transaction >> > >> > and >> > >> > reliable messaging suppport, >> > >> > >> > >> > >> > >> >> > >> http://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ >> > >> > >> > >> > You'll find all the interfaces for the IL as well as interfaces the >> > >> engine >> > >> > exposes to the outside world. >> > >> > >> > >> > You can also take a look at the existing implementations (Axis2 and >> > JBI) >> > >> to >> > >> > get a better understanding and starting for the implementation, >> since >> > >> > there >> > >> > are usually (some) pieces that can be reused across ILs. >> > >> > >> > >> >> > >> To complement the list, there's also an IL for ODE in Tuscany: >> > >> >> > >> >> > >> >> > >> http://svn.apache.org/repos/asf/tuscany/java/sca/modules/implementation-bpel-ode/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/ >> > >> >> > >> The EmbeddedODEServer is a good starting point as it wires up the >> strict >> > >> minimum resources necessary for ODE to run. >> > >> >> > >> Matthieu >> > >> >> > >> >> > >> > >> > >> > Ask questions if you need help... >> > >> > >> > >> > alex >> > >> > >> > >> > On Thu, Jul 31, 2008 at 5:33 PM, Ivan Trajkovic < >> > [EMAIL PROTECTED] >> > >> > >wrote: >> > >> > >> > >> > > hello everyone >> > >> > > Im pretty intrigued about ODE's capabilities, and would like to >> > start >> > >> > > integrating it into my new system. >> > >> > > I was wondering if there was a place where I could read up more >> > about >> > >> how >> > >> > > to >> > >> > > go about integrating my classes into the Integration Layer so to >> > have >> > >> > those >> > >> > > functions available as services from within my BPEL processes. I >> > would >> > >> > > prefer this approach to avoid slowdowns/inefficiencies due to >> SOAP >> > >> > > parsing/transmission. The classes are written in Scala, but this >> is >> > a >> > >> > > non-issue since it all compiles down to JVM bytecode and looks >> the >> > >> same >> > >> > to >> > >> > > ODE at runtime. >> > >> > > Im still not sure how well this would scale, and Im assuming that >> it >> > >> > would >> > >> > > pretty much mean that I would have to make my class methods >> > >> > > re-entrant/stateless. >> > >> > > I've looked at the Javadocs but this is a pretty harsh way to >> start >> > >> from >> > >> > > scratch when there's no clue about what are the primary things to >> > get >> > >> > > familiar with. >> > >> > > >> > >> > > thank you for your help, its very much appreciated. >> > >> > > >> > >> > >> > >> >> > > >> > > >> > >> > >
