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
