Re: Any plans for...

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