Hi Tammo, Thank you for the source and the detail I'll go through this and figure out the functionalities. And as you mentioned that ODE IL is not much aware of WS-* standards JAX WS approach seems possible for implement a JAX WS IL . What do you think ?
On 15 March 2014 00:17, Tammo van Lessen <tvanles...@gmail.com> wrote: > Hi Ujitha, > > no, I'm afraid its not documented in a single place. I guess the best > source is the code at > > https://github.com/apache/ode/tree/master/axis2/src/main/java/org/apache/ode/axis2 > > Its basically what axis2 provides for exposing and consuming services but > with some proprietary adjustments for JMS (which IIRC add a dead letter > queue or something. It would give that less priority and check what CXF > could provide). It also maps ODE's implicit correlation mechanism to Axis2. > This needs to be implemented as well. This feature currently uses custom > headers, but I think meanwhile it could be nicely implemented with > WS-Addressing, which would be more standards compliant and can probably be > implemented with plain JAXWS. > > In addition to that, it also implements the process/instance management > service and the deployment service. > > HTH, > Tammo > > > On Thu, Mar 13, 2014 at 5:55 PM, Ujitha Iroshan <dguji...@gmail.com> > wrote: > > > Hi Tammo, > > > > Is there any detailed documentation that I can find about > functionalities > > that are implemented in the Axis2 IL and the basic functionalities of IL > ? > > > > Best Regards > > Ujitha > > > > > > On 13 March 2014 20:47, Fang Zhen <fangzhenz...@gmail.com> wrote: > > > > > Hi All, > > > I have noticed OModel serialization issues before. The only problem is > > that > > > OModel refactoring is not so important at my point when use ODE. So I > did > > > not think it over and somewhat ignored it. However, I'm still > interested > > in > > > it. I think I could work on it, and here I'd like to talk about my > > > understanding on the issue. > > > > > > In my view, OModel gives a compiled representation of BPEL elements. > The > > > OModel objects are serialized for permanent store and exchange. It > relies > > > on java serialization mechanism which is not flexible enough, so > problem > > > occurs when we need evolve the existing OModel classes or new OModel > > > classes or share objects in cluster. > > > The candidate new serialization solutions are mainly in two ways. > First, > > we > > > could store a Map<String, Object> and wrap all data that is currently > > > stored in field in this Map. And the java serialization mechanism can > > still > > > be used. Another way is that we employ a new serialization mechanism > like > > > Jackson. > > > Another important problem is that how we can migrate to the new OModel. > > And > > > as Tammo says, is the most difficult part. Roughly thinking, it > involves > > > many sub-projects like compiler, store, dao and underlying database. > But > > I > > > konw little about the details. > > > This is my preliminary understanding on OModel refactor. Hoping for > > > suggestions and corrections. > > > Should we open a new thread for OModel refactor topic? > > > > > > Thanks, > > > Zhen > > > > > > > > > > > -- > > Ujitha Iroshan Wickramarathna > > Undergraduate > > Department of Computer Science and Engineering > > University of Moratuwa. > > > > > > -- > Tammo van Lessen - http://www.taval.de > -- Ujitha Iroshan Wickramarathna Undergraduate Department of Computer Science and Engineering University of Moratuwa.
