You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsif-user@ws.apache.org by Andrzej Jan Taramina <an...@chaeron.com> on 2005/11/18 01:43:20 UTC
Any plans for...
WSDL 2.0 support?
HTTP Provider (Rest style Get/Post/Put/Delete/Head)?
Or is WSIF on the maintenance shelf and heading towards obsolescence (which
would be a big shame!)?
Thanks!
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
Re: Any plans for...
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Alek:
> +1 and i help as much as i can (which sometimes is limited)
I can relate to that....my time is sometimes very limited as well, but it
would be a shame to see WSIF wither away for lack of attention.
There have been some comments made about JBI eventually replacing WSIF, but
upon reading the JBI spec, they seem pretty much orthogonal to me. Though I
suppose WSIF could be rearchitected to use JBI under the covers. I don't see
much value to that approach at the moment.
> i played with some prototype WSIF extensions including advanced
> correlation support, simple client side handlers, server side WSIF-like
> services (based on WSDL - generate Java interface and all the rest is
> done by pluggable service layer) etc. in XSUL2. all code is under
> BSD-like license and you can find examples and documentation at the
> homepage.
I was thinking about server side WSIF-like services as well. I'll take a
look and see what you've come up with.
It seems like XSUL2 is intended as a next-gen replacement for WSIF? How
compatible is it with the WSIF interfaces?
The reason I ask is that my primary motivation for using WSIF on a current
client project is to allow us to plug in external BPEL engines down the road,
which all use WSIF to extend their BPEL integration to more than just classic
SOAP Webservices. Switching to a different API wouldn't work in that case.
> if it looks interesting maybe we can start a scratch project and get
> some new APIs/providers done such as REST style WSIF?
I'm interested but not yet sure how much time/effort I want to devode to
extending WSIF. Partially based on limited spare time....and partially
because I don't yet know enough about WSIF, it's future directions (if any),
quality of the code base (haven't had a chance to look at the code much),
etc.
I'll let you know...
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
Re: Any plans for...
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:
>Andrzej,
>
>you are welcome to contribute and make it a bigger/better :) It's an
>open source project after all.
>
>
+1 and i help as much as i can (which sometimes is limited)
i played with some prototype WSIF extensions including advanced
correlation support, simple client side handlers, server side WSIF-like
services (based on WSDL - generate Java interface and all the rest is
done by pluggable service layer) etc. in XSUL2. all code is under
BSD-like license and you can find examples and documentation at the
homepage.
if it looks interesting maybe we can start a scratch project and get
some new APIs/providers done such as REST style WSIF?
thanks,
alek
>-- dims
>
>On 11/17/05, Andrzej Jan Taramina <an...@chaeron.com> wrote:
>
>
>>WSDL 2.0 support?
>>
>>HTTP Provider (Rest style Get/Post/Put/Delete/Head)?
>>
>>Or is WSIF on the maintenance shelf and heading towards obsolescence (which
>>would be a big shame!)?
>>
>>Thanks!
>>
>>
>>Andrzej Jan Taramina
>>Chaeron Corporation: Enterprise System Solutions
>>http://www.chaeron.com
>>
>>
>>
>>
>
>
>--
>Davanum Srinivas : http://wso2.com/blogs/
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: Any plans for...
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Andrzej Jan Taramina wrote:
>Alek:
>
>
>
>>key client side abstractions i have prorotyped are XService (that
>>represents a local objects that provides access to a service described
>>in a WSDL):
>>
>>
>
>I'm thinking that there would be value in keeping the client and server side
>stuff separate. Or at least modular enough that you can pick/choose which
>you want.
>
>
it is completely separate (or as separate as you want - still you can
expose service on local machine, the same JVM etc) with some extra work
to host (local Java, BeanShell, whatnot) or bridge to existing services
(like EJB).
>I expect more folks will want the WSIF-style client invocation API rather
>than the server side service implementation stuff. Primarily because there
>are already a lot of toolkits that generate the latter.
>
>
true but you need minimal server side to do true asynchronous invocation
as in such situation you are doing peer-2-peer computing not
client-server (every client is at least on logical level also a server -
sai that you can use intermediaries such as WS-MsgBox service to allow
client that can not have listening socket - ex. applet - to pull
messages ...)
>
>
>>think about it as a *prototype* for next-gen WSIF - if there is
>>something useful then it may be used (or improved) in the next WSIF
>>
>>
>
>Ah! Now I understand. Excellent!
>
>
;-)
>
>
>>direction and everything else depends on users and where they want to
>>take it ... it is that simple and WSIF definitely needs more active
>>developers :)
>>
>>
>
>+1 on that.
>
>No decisions yet, and given how close the Xmas season is, I might not make a
>decision till after the holidays.
>
>But I am tempted by the thought of extending the inventory of WSIF providers
>to include REST/HTTP (I believe Oracle has this already...sad that they
>haven't donated it back to the WSIF project), ebXML Message Service and also
>updates to be able to handle the impending WSDL 2.0 spec.
>
>
>
cool!
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Any plans for...
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Alek:
> key client side abstractions i have prorotyped are XService (that
> represents a local objects that provides access to a service described
> in a WSDL):
I'm thinking that there would be value in keeping the client and server side
stuff separate. Or at least modular enough that you can pick/choose which
you want.
I expect more folks will want the WSIF-style client invocation API rather
than the server side service implementation stuff. Primarily because there
are already a lot of toolkits that generate the latter.
> think about it as a *prototype* for next-gen WSIF - if there is
> something useful then it may be used (or improved) in the next WSIF
Ah! Now I understand. Excellent!
> direction and everything else depends on users and where they want to
> take it ... it is that simple and WSIF definitely needs more active
> developers :)
+1 on that.
No decisions yet, and given how close the Xmas season is, I might not make a
decision till after the holidays.
But I am tempted by the thought of extending the inventory of WSIF providers
to include REST/HTTP (I believe Oracle has this already...sad that they
haven't donated it back to the WSIF project), ebXML Message Service and also
updates to be able to handle the impending WSDL 2.0 spec.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
Re: Any plans for...
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Andrzej Jan Taramina wrote:
>Alek:
>
>
>
>>+1 and i help as much as i can (which sometimes is limited)
>>
>>
>
>I can relate to that....my time is sometimes very limited as well, but it
>would be a shame to see WSIF wither away for lack of attention.
>
>There have been some comments made about JBI eventually replacing WSIF, but
>upon reading the JBI spec, they seem pretty much orthogonal to me. Though I
>suppose WSIF could be rearchitected to use JBI under the covers. I don't see
>much value to that approach at the moment.
>
>
>
>>i played with some prototype WSIF extensions including advanced
>>correlation support, simple client side handlers, server side WSIF-like
>>services (based on WSDL - generate Java interface and all the rest is
>>done by pluggable service layer) etc. in XSUL2. all code is under
>>BSD-like license and you can find examples and documentation at the
>>homepage.
>>
>>
>
>I was thinking about server side WSIF-like services as well. I'll take a
>look and see what you've come up with.
>
>
key client side abstractions i have prorotyped are XService (that
represents a local objects that provides access to a service described
in a WSDL):
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xservo/xsul/xservo/
and XHandler (the same for client and server side) that simply can
modify XML infoset of a message (handlers can communicate using a
context object passed to them in a pipeline that is also XML infoset
element):
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xhandler/xsul/xhandler/
XService can be exposed by many means and currently i have a simple one
using embedded simple web server:
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xservo_soap_http/xsul/xservo_soap_http/
XService has currently just two implementations: one pure XML infoset
(default) that uses Java reflection and passes XML message as XML
Infoset element to the method
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xservo_soap/xsul/xservo_soap/XSoapDocLiteralService.java
and another based on XmlBeans (XML message parts are mapped to XmlBeans
generated java classes):
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xservices_xbeans/xsul/xservices_xbeans/
>It seems like XSUL2 is intended as a next-gen replacement for WSIF?
>
think about it as a *prototype* for next-gen WSIF - if there is
something useful then it may be used (or improved) in the next WSIF
> How
>compatible is it with the WSIF interfaces?
>
>
it actually implements subset of WSIF interfaces (to avoid any possible
confusion they are in different package) and it strictly separates API
from providers (implementation):
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xwsif/xsul/wsif/
>The reason I ask is that my primary motivation for using WSIF on a current
>client project is to allow us to plug in external BPEL engines down the road,
>which all use WSIF to extend their BPEL integration to more than just classic
>SOAP Webservices. Switching to a different API wouldn't work in that case.
>
>
i agree and you still have great deal of freedom as you can implement
your custom interfaces on top of WSIF such as i did with WSIFClient
which provides higher level interface to allow client side handlers and
dynamic stubs on top of WSIF API:
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xwsif_runtime/xsul/xwsif_runtime/
>>if it looks interesting maybe we can start a scratch project and get
>>some new APIs/providers done such as REST style WSIF?
>>
>>
>
>I'm interested but not yet sure how much time/effort I want to devode to
>extending WSIF. Partially based on limited spare time....and partially
>because I don't yet know enough about WSIF, it's future directions (if any),
>quality of the code base (haven't had a chance to look at the code much),
>etc.
>
>
direction and everything else depends on users and where they want to
take it ... it is that simple and WSIF definitely needs more active
developers :)
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Any plans for...
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Andrzej Jan Taramina wrote:
>Alek:
>
>
>
>>+1 and i help as much as i can (which sometimes is limited)
>>
>>
>
>I can relate to that....my time is sometimes very limited as well, but it
>would be a shame to see WSIF wither away for lack of attention.
>
>There have been some comments made about JBI eventually replacing WSIF, but
>upon reading the JBI spec, they seem pretty much orthogonal to me. Though I
>suppose WSIF could be rearchitected to use JBI under the covers. I don't see
>much value to that approach at the moment.
>
>
>
>>i played with some prototype WSIF extensions including advanced
>>correlation support, simple client side handlers, server side WSIF-like
>>services (based on WSDL - generate Java interface and all the rest is
>>done by pluggable service layer) etc. in XSUL2. all code is under
>>BSD-like license and you can find examples and documentation at the
>>homepage.
>>
>>
>
>I was thinking about server side WSIF-like services as well. I'll take a
>look and see what you've come up with.
>
>
key client side abstractions i have prorotyped are XService (that
represents a local objects that provides access to a service described
in a WSDL):
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xservo/xsul/xservo/
and XHandler (the same for client and server side) that simply can
modify XML infoset of a message (handlers can communicate using a
context object passed to them in a pipeline that is also XML infoset
element):
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xhandler/xsul/xhandler/
XService can be exposed by many means and currently i have a simple one
using embedded simple web server:
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xservo_soap_http/xsul/xservo_soap_http/
XService has currently just two implementations: one pure XML infoset
(default) that uses Java reflection and passes XML message as XML
Infoset element to the method
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xservo_soap/xsul/xservo_soap/XSoapDocLiteralService.java
and another based on XmlBeans (XML message parts are mapped to XmlBeans
generated java classes):
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xservices_xbeans/xsul/xservices_xbeans/
>It seems like XSUL2 is intended as a next-gen replacement for WSIF?
>
think about it as a *prototype* for next-gen WSIF - if there is
something useful then it may be used (or improved) in the next WSIF
> How
>compatible is it with the WSIF interfaces?
>
>
it actually implements subset of WSIF interfaces (to avoid any possible
confusion they are in different package) and it strictly separates API
from providers (implementation):
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xwsif/xsul/wsif/
>The reason I ask is that my primary motivation for using WSIF on a current
>client project is to allow us to plug in external BPEL engines down the road,
>which all use WSIF to extend their BPEL integration to more than just classic
>SOAP Webservices. Switching to a different API wouldn't work in that case.
>
>
i agree and you still have great deal of freedom as you can implement
your custom interfaces on top of WSIF such as i did with WSIFClient
which provides higher level interface to allow client side handlers and
dynamic stubs on top of WSIF API:
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/modules/xwsif_runtime/xsul/xwsif_runtime/
>>if it looks interesting maybe we can start a scratch project and get
>>some new APIs/providers done such as REST style WSIF?
>>
>>
>
>I'm interested but not yet sure how much time/effort I want to devode to
>extending WSIF. Partially based on limited spare time....and partially
>because I don't yet know enough about WSIF, it's future directions (if any),
>quality of the code base (haven't had a chance to look at the code much),
>etc.
>
>
direction and everything else depends on users and where they want to
take it ... it is that simple and WSIF definitely needs more active
developers :)
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Any plans for...
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Davanum :
> you are welcome to contribute and make it a bigger/better :) It's an
> open source project after all.
Thanks for stating the obvious. Very helpful response. ;-)
However, this doesn't address any of my inquiries about any existing future
plans or current status of WSIF, the answers to which will influence my
decision on whether and how much to participate on WSIF.
> > WSDL 2.0 support?
> >
> > HTTP Provider (Rest style Get/Post/Put/Delete/Head)?
> >
> > Or is WSIF on the maintenance shelf and heading towards obsolescence (which
> > would be a big shame!)?
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
Re: Any plans for...
Posted by Davanum Srinivas <da...@gmail.com>.
Andrzej,
you are welcome to contribute and make it a bigger/better :) It's an
open source project after all.
-- dims
On 11/17/05, Andrzej Jan Taramina <an...@chaeron.com> wrote:
> WSDL 2.0 support?
>
> HTTP Provider (Rest style Get/Post/Put/Delete/Head)?
>
> Or is WSIF on the maintenance shelf and heading towards obsolescence (which
> would be a big shame!)?
>
> Thanks!
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
--
Davanum Srinivas : http://wso2.com/blogs/