HI Tammo, I have found an article describing adding WS security in JAX WS by adding wsse security headers to client side with WSS User Token. I roughly go through it and it might be a way to implement the support of WS security in IL. And can we get the support of Metro stack along with the JAX WS implementation which is also reference implementation of JAX WS so we can easily implement the functionality that are beyond the JAX WS ?
Best regards Ujitha On 17 March 2014 18:17, Tammo van Lessen <tvanles...@gmail.com> wrote: > Hi Ujitha, > > in ode-axis2-war it adds also support for WS-Security using Rampart, but > only via additional config files. I think this part should remain in the > responsibility of the IL implementation, and thus also in the > responsibility of the JAXWS implementation. I think we need to find a way > to configured them accordingly but as the IL itself it not aware of it, the > JAXWS IL doesn't have to be either. > > Best, > Tammo > > > On Fri, Mar 14, 2014 at 8:17 PM, Ujitha Iroshan <dguji...@gmail.com> > wrote: > > > 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. > > > > > > -- > Tammo van Lessen - http://www.taval.de > -- Ujitha Iroshan Wickramarathna Undergraduate Department of Computer Science and Engineering University of Moratuwa.
