Re: Axis2 WS binding next steps
Hi, Ant. I volunteer to look into the Axis2 DataBinding integration. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Thursday, March 09, 2006 5:51 AM Subject: Re: Axis2 WS binding next steps I've raised a bunch of JIRA's for these (except for 8 and 9 which we can look at later). Probably the highest priority right now is the documentation on the website and wiki, and after that some of the easier JIRAs. I'm going off to work on the samples and doc for the JavaScript component so be great if some others could volunteer do do this WS work (Rick? Raymond? anyone else?). ...ant On 3/8/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > ant elder wrote: > > Forgot one: > > > > 10) Support invoking simple rpc encoded remote services. Not proper > rpc-enc > > support but tuscany working for things like xmethods stockquote which > i'm > > sure lots of new users will try. Currently SDO barfs on the WSDL but if > it > > could tolerate it those simple services often work even if the soap > message > > doesn't have the xsi type stuff. > > > > On 3/6/06, ant elder <[EMAIL PROTECTED]> wrote: > > > >> Now that we have the WS binding going using Axis2 can we come up with a > >> list of what improvements we need to make to it in the nearish future. > If we > >> can come up with a list of task, prioritize it, see who volunteers for > what, > >> then we'll know what we can do and how long it will take before the > >> bindings ready for another point-in-time stable build. > >> > >> 1) Documentation. At very least something simple explaining how > components > >> use externalServices to call remote services and how to use entryPoints > >> expose components as Web service endpoints. > >> > >> 2) Fix bugs. There's a few JIRA's already, sure we can find some more > if > >> we play around using the axis binding. > >> > >> 3) Clean up the code and flesh out the tests. (should the project be > >> renamed from binding.axis to binding.ws? ...or should container.js be > >> renamed to container.rhino?) > >> > >> 4) Correctly configure the AxisService in ExternalWebServiceClient. As > the > >> TODO in the code says and several people have already commented, on > this > >> should not use the axis.xml but be configured programatically. The > >> requires moving up from Axis2 0.94. > >> > >> 5) Java2WSDL tooling using the Axis2 tools. Also requires moving up > from > >> Axis2 0.94. > >> > >> 6) Move up to a later release from Axis2 0.94 to get several fixes and > to > >> support the last two items. > >> > >> 7) Support efficient (de)serilization and streaming between > >> components/services. Ideally i'd like to be able to wire up a WS > entryPoint > >> to an externalService or e4x component and have the SOAP body pulled > >> directly from the incoming StaX stream. > >> > >> 8) Policy. Once (4) and (5) are done it should be possible to use a > WSDL > >> with policy on an externalService and have things like WS-Security > >> automatically configured by Axis2, so investigate this and see what can > be > >> done on the entryPoint. > >> > >> 9) look at using alternative WS impls to Axis2? XFIRE's just had a > 1.0release, or JAX-WS? Maybe not a high priority but i'm sure we could > learn > >> things from trying this. > >> > >> Comments? What else can people think off? > >> > >>...ant > >> > >> > >> > > > > > Ant, this looks very good. I would like to add one item: > > 11) Open our data binding implementation and integrate it with the Axis2 > data binding story. Currently our serialization/de-serialization code > assumes SDO DataObjects. Application developers will also want to be > able to use plain JavaBeans, Axis2 generated beans etc. > > -- > Jean-Sebastien > >
Re: Axis2 WS binding next steps
I've raised a bunch of JIRA's for these (except for 8 and 9 which we can look at later). Probably the highest priority right now is the documentation on the website and wiki, and after that some of the easier JIRAs. I'm going off to work on the samples and doc for the JavaScript component so be great if some others could volunteer do do this WS work (Rick? Raymond? anyone else?). ...ant On 3/8/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > ant elder wrote: > > Forgot one: > > > > 10) Support invoking simple rpc encoded remote services. Not proper > rpc-enc > > support but tuscany working for things like xmethods stockquote which > i'm > > sure lots of new users will try. Currently SDO barfs on the WSDL but if > it > > could tolerate it those simple services often work even if the soap > message > > doesn't have the xsi type stuff. > > > > On 3/6/06, ant elder <[EMAIL PROTECTED]> wrote: > > > >> Now that we have the WS binding going using Axis2 can we come up with a > >> list of what improvements we need to make to it in the nearish future. > If we > >> can come up with a list of task, prioritize it, see who volunteers for > what, > >> then we'll know what we can do and how long it will take before the > >> bindings ready for another point-in-time stable build. > >> > >> 1) Documentation. At very least something simple explaining how > components > >> use externalServices to call remote services and how to use entryPoints > >> expose components as Web service endpoints. > >> > >> 2) Fix bugs. There's a few JIRA's already, sure we can find some more > if > >> we play around using the axis binding. > >> > >> 3) Clean up the code and flesh out the tests. (should the project be > >> renamed from binding.axis to binding.ws? ...or should container.js be > >> renamed to container.rhino?) > >> > >> 4) Correctly configure the AxisService in ExternalWebServiceClient. As > the > >> TODO in the code says and several people have already commented, on > this > >> should not use the axis.xml but be configured programatically. The > >> requires moving up from Axis2 0.94. > >> > >> 5) Java2WSDL tooling using the Axis2 tools. Also requires moving up > from > >> Axis2 0.94. > >> > >> 6) Move up to a later release from Axis2 0.94 to get several fixes and > to > >> support the last two items. > >> > >> 7) Support efficient (de)serilization and streaming between > >> components/services. Ideally i'd like to be able to wire up a WS > entryPoint > >> to an externalService or e4x component and have the SOAP body pulled > >> directly from the incoming StaX stream. > >> > >> 8) Policy. Once (4) and (5) are done it should be possible to use a > WSDL > >> with policy on an externalService and have things like WS-Security > >> automatically configured by Axis2, so investigate this and see what can > be > >> done on the entryPoint. > >> > >> 9) look at using alternative WS impls to Axis2? XFIRE's just had a > 1.0release, or JAX-WS? Maybe not a high priority but i'm sure we could > learn > >> things from trying this. > >> > >> Comments? What else can people think off? > >> > >>...ant > >> > >> > >> > > > > > Ant, this looks very good. I would like to add one item: > > 11) Open our data binding implementation and integrate it with the Axis2 > data binding story. Currently our serialization/de-serialization code > assumes SDO DataObjects. Application developers will also want to be > able to use plain JavaBeans, Axis2 generated beans etc. > > -- > Jean-Sebastien > >
Re: Axis2 WS binding next steps
ant elder wrote: Forgot one: 10) Support invoking simple rpc encoded remote services. Not proper rpc-enc support but tuscany working for things like xmethods stockquote which i'm sure lots of new users will try. Currently SDO barfs on the WSDL but if it could tolerate it those simple services often work even if the soap message doesn't have the xsi type stuff. On 3/6/06, ant elder <[EMAIL PROTECTED]> wrote: Now that we have the WS binding going using Axis2 can we come up with a list of what improvements we need to make to it in the nearish future. If we can come up with a list of task, prioritize it, see who volunteers for what, then we'll know what we can do and how long it will take before the bindings ready for another point-in-time stable build. 1) Documentation. At very least something simple explaining how components use externalServices to call remote services and how to use entryPoints expose components as Web service endpoints. 2) Fix bugs. There's a few JIRA's already, sure we can find some more if we play around using the axis binding. 3) Clean up the code and flesh out the tests. (should the project be renamed from binding.axis to binding.ws? ...or should container.js be renamed to container.rhino?) 4) Correctly configure the AxisService in ExternalWebServiceClient. As the TODO in the code says and several people have already commented, on this should not use the axis.xml but be configured programatically. The requires moving up from Axis2 0.94. 5) Java2WSDL tooling using the Axis2 tools. Also requires moving up from Axis2 0.94. 6) Move up to a later release from Axis2 0.94 to get several fixes and to support the last two items. 7) Support efficient (de)serilization and streaming between components/services. Ideally i'd like to be able to wire up a WS entryPoint to an externalService or e4x component and have the SOAP body pulled directly from the incoming StaX stream. 8) Policy. Once (4) and (5) are done it should be possible to use a WSDL with policy on an externalService and have things like WS-Security automatically configured by Axis2, so investigate this and see what can be done on the entryPoint. 9) look at using alternative WS impls to Axis2? XFIRE's just had a 1.0release, or JAX-WS? Maybe not a high priority but i'm sure we could learn things from trying this. Comments? What else can people think off? ...ant Ant, this looks very good. I would like to add one item: 11) Open our data binding implementation and integrate it with the Axis2 data binding story. Currently our serialization/de-serialization code assumes SDO DataObjects. Application developers will also want to be able to use plain JavaBeans, Axis2 generated beans etc. -- Jean-Sebastien
Re: Axis2 WS binding next steps
On Mar 6, 2006, at 4:14 AM, ant elder wrote: Now that we have the WS binding going using Axis2 can we come up with a list of what improvements we need to make to it in the nearish future. If we can come up with a list of task, prioritize it, see who volunteers for what, then we'll know what we can do and how long it will take before the bindings ready for another point-in-time stable build. 1) Documentation. At very least something simple explaining how components use externalServices to call remote services and how to use entryPoints expose components as Web service endpoints. 2) Fix bugs. There's a few JIRA's already, sure we can find some more if we play around using the axis binding. 3) Clean up the code and flesh out the tests. (should the project be renamed from binding.axis to binding.ws? ...or should container.js be renamed to container.rhino?) My own preference would be something with "Axis" in it since there will be other ws binding implementations. So, I guess the same goes for container.js --> container.rhino 4) Correctly configure the AxisService in ExternalWebServiceClient. As the TODO in the code says and several people have already commented, on this should not use the axis.xml but be configured programatically. The requires moving up from Axis2 0.94. I think we should also remove the dependency on getAggregate and do something similar to what Jeremy recommended. I'm happy to help out if there are no takers (but have plenty of other things to work on if someone is interested) 5) Java2WSDL tooling using the Axis2 tools. Also requires moving up from Axis2 0.94. 6) Move up to a later release from Axis2 0.94 to get several fixes and to support the last two items. 7) Support efficient (de)serilization and streaming between components/services. Ideally i'd like to be able to wire up a WS entryPoint to an externalService or e4x component and have the SOAP body pulled directly from the incoming StaX stream. 8) Policy. Once (4) and (5) are done it should be possible to use a WSDL with policy on an externalService and have things like WS-Security automatically configured by Axis2, so investigate this and see what can be done on the entryPoint. 9) look at using alternative WS impls to Axis2? XFIRE's just had a 1.0release, or JAX-WS? Maybe not a high priority but i'm sure we could learn things from trying this. Comments? What else can people think off? ...ant
Re: Axis2 WS binding next steps
Forgot one: 10) Support invoking simple rpc encoded remote services. Not proper rpc-enc support but tuscany working for things like xmethods stockquote which i'm sure lots of new users will try. Currently SDO barfs on the WSDL but if it could tolerate it those simple services often work even if the soap message doesn't have the xsi type stuff. On 3/6/06, ant elder <[EMAIL PROTECTED]> wrote: > > Now that we have the WS binding going using Axis2 can we come up with a > list of what improvements we need to make to it in the nearish future. If we > can come up with a list of task, prioritize it, see who volunteers for what, > then we'll know what we can do and how long it will take before the > bindings ready for another point-in-time stable build. > > 1) Documentation. At very least something simple explaining how components > use externalServices to call remote services and how to use entryPoints > expose components as Web service endpoints. > > 2) Fix bugs. There's a few JIRA's already, sure we can find some more if > we play around using the axis binding. > > 3) Clean up the code and flesh out the tests. (should the project be > renamed from binding.axis to binding.ws? ...or should container.js be > renamed to container.rhino?) > > 4) Correctly configure the AxisService in ExternalWebServiceClient. As the > TODO in the code says and several people have already commented, on this > should not use the axis.xml but be configured programatically. The > requires moving up from Axis2 0.94. > > 5) Java2WSDL tooling using the Axis2 tools. Also requires moving up from > Axis2 0.94. > > 6) Move up to a later release from Axis2 0.94 to get several fixes and to > support the last two items. > > 7) Support efficient (de)serilization and streaming between > components/services. Ideally i'd like to be able to wire up a WS entryPoint > to an externalService or e4x component and have the SOAP body pulled > directly from the incoming StaX stream. > > 8) Policy. Once (4) and (5) are done it should be possible to use a WSDL > with policy on an externalService and have things like WS-Security > automatically configured by Axis2, so investigate this and see what can be > done on the entryPoint. > > 9) look at using alternative WS impls to Axis2? XFIRE's just had a > 1.0release, or JAX-WS? Maybe not a high priority but i'm sure we could learn > things from trying this. > > Comments? What else can people think off? > >...ant > >
Axis2 WS binding next steps
Now that we have the WS binding going using Axis2 can we come up with a list of what improvements we need to make to it in the nearish future. If we can come up with a list of task, prioritize it, see who volunteers for what, then we'll know what we can do and how long it will take before the bindings ready for another point-in-time stable build. 1) Documentation. At very least something simple explaining how components use externalServices to call remote services and how to use entryPoints expose components as Web service endpoints. 2) Fix bugs. There's a few JIRA's already, sure we can find some more if we play around using the axis binding. 3) Clean up the code and flesh out the tests. (should the project be renamed from binding.axis to binding.ws? ...or should container.js be renamed to container.rhino?) 4) Correctly configure the AxisService in ExternalWebServiceClient. As the TODO in the code says and several people have already commented, on this should not use the axis.xml but be configured programatically. The requires moving up from Axis2 0.94. 5) Java2WSDL tooling using the Axis2 tools. Also requires moving up from Axis2 0.94. 6) Move up to a later release from Axis2 0.94 to get several fixes and to support the last two items. 7) Support efficient (de)serilization and streaming between components/services. Ideally i'd like to be able to wire up a WS entryPoint to an externalService or e4x component and have the SOAP body pulled directly from the incoming StaX stream. 8) Policy. Once (4) and (5) are done it should be possible to use a WSDL with policy on an externalService and have things like WS-Security automatically configured by Axis2, so investigate this and see what can be done on the entryPoint. 9) look at using alternative WS impls to Axis2? XFIRE's just had a 1.0release, or JAX-WS? Maybe not a high priority but i'm sure we could learn things from trying this. Comments? What else can people think off? ...ant
