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
