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 Tim Williams <ha...@hotmail.com> on 2004/01/17 05:57:37 UTC
Status update
What is the status of WSIF?
Has development stopped or are there plans for the future...?
Tim.
WSIF0002E Message
Posted by Leo Barcenas <le...@sd-net.co.jp>.
Hi !
This is probably a very simple task for everyone, but, I can't
simply make it work.
I am trying not to show the message "WSIF0002E . . . . " whenever
a non-existing web service is called. But to no avail.
I am using the binary release of WSIF2.0. I am thinking of editing the
WSIF source code and recompiling it. But, it will be taking me much time
to do it. Perhaps if some of you have an idea on how to erase the message.
I already catch all the exceptions that I know of but, the message still
shows.
Hoping for your response.
Thanks in advance.
Leo Barcenas
Re: Status update
Posted by Eric Swindell <er...@att.net>.
> >where you can have all kinds of services running in an dynamic environment
> > in which they may come and go, and get substituted with other comparable
> > services with the same interfaces.
>
> so it must have intermediate broker service to mediate between ever
> changing components?
Yes, the OSGi Framework manages all of this. However, you have to code to
anticipate service additions and removals. ServiceBinder removes a lot of
tedious code by simpling calling your 'add/removeService' methods and
managing service relationships. Since you've gone thru Richard's tutorial by
now, I'm sure you get the jest of it :)
>
> > An application is merely a bunch of
> >components offerring and requiring services. Warning: playing with this
> >stuff can be quite addictive!
>
> we have something called XCAT that is a toolkit to write distributed
> component.
>
> each component can declare what ports it needs ("uses") and what ports
> it makes available for others ("provides"). then you connect uses ports
> with compatible provides ports and a distributed application is created :-)
Interesting. I suppose you could apply this with OSGi so that http services
expect and require certain ports. There is a standard OSGi http service
interface in the specification ( downloadable at OSGi's web site ), which is
implemented in Oscar via Jetty.
One idea I've thought about is having OSGi Frameworks running on different
servers and the Framework running on the clients, and having the local
services interact with the remote services of the servers. It would sort of
extend-out the OSGi service model so that services could be local or remote,
and the client wouldn't be concerned with it. For example, when a client is
up and running in a disconnected state, it would use local services, but when
connected to the net, it would have additional and sometimes complementary
services available to it from the servers. That's what got me interested in
WSIF, where we could have an OSGi service running on the client which may
utilize other local services which tie in to remote services via different
'providers' ( as you say :) ).
Alternatively, instead of having local service to remote service tie-ins,
something like ServiceBinder, which depends on xml descriptors of services
and their relationships with other services, might be extended to define or
rely on remote services ( perhaps tie in to their WSDL definitions ). So you
wouldn't need that extra local-remote layer; to the Framework, they would all
just be considered services, whether local or remote. ServiceBinder, or
something like it, would be responsible for managing the service lifecycle,
whether local or remote. Also, the remote services wouldn't have to
necessarily be pure OSGi services; they could just be considered remote
services, such as web services, EJB, JMS, and be abstracted out via WSIF so
that it wouldn't matter what kind of service they actually were.
> >I really like how easy it seems to do digital signatures on each end. I'm
> > not even sure how to do that with AXIS,
>
> there is already project to do this for AXIS called WSS4J see
> http://sourceforge.net/projects/wss4j/ (WSS4J provides AXIS handlers
> dsig work easy and comes with examples)
Thanks. I'll check it out.
> we use it for all kinds of stuff so over time when it stabilizes i will
> make it available probably around time when JDK 1.5 reaches beta so i
> can take advantage of all syntax sugars and other niceties such as
> generics and for-each loops ...
Great! Look forward to it.
> you can use also toolkits such as castor or xml beans
> (http://xml.apache.org/xmlbeans/) to bind XML infoset to Java beans
> generated from XML schema.
Thanks. I hadn't done enough exploring back then and was just using
home-grown techniques, but now I'm aware of castor and XMLBeans. However, I
haven't use either yet. There are so many things to explore...
> >number of examples. The tutorial is a great way to get up to speed with
> >OSGi.
>
> i am just reading it - it looks good.
If you want more info, Richard has published a few academic papers regarding
his research and philosophical ideas regarding components and services. If
you ask, he'll likely send you one.
Eric
Re: Status update
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Eric Swindell wrote:
>>i think it is pretty stable.
>>
>>
>
>That is good to hear!
>
>
>
>>so i wanted something that in its core is very modular to allow true
>>plug&play or in OO words a toolkit that makes it easy to create and use
>>web service by combining and extending existing modules. that is exactly
>>how i designed XSOAP4. its alternative name is XSUL which stands for XML
>>Services Utility Library and that is its philosophy: lot of pluggable
>>modules.
>>
>>
>
>Since I've been doing a lot of coding with OSGi services lately, I'm really
>into the 'pluggable' mindset as well where the interface drives the car
>instead of the implementation. Of course, extending existing implementations
>which meet one's needs is great too, and increases code reuse. You can think
>of an OSGi Framework as a kind of mini application services kernel ( hey, it
>might not be the official techno-speak, but it's one way to describe it ),
>
>
sounds intriguing!
>where you can have all kinds of services running in an dynamic environment in
>which they may come and go, and get substituted with other comparable
>services with the same interfaces.
>
so it must have intermediate broker service to mediate between ever
changing components?
> An application is merely a bunch of
>components offerring and requiring services. Warning: playing with this
>stuff can be quite addictive!
>
>
we have something called XCAT that is a toolkit to write distributed
component.
each component can declare what ports it needs ("uses") and what ports
it makes available for others ("provides"). then you connect uses ports
with compatible provides ports and a distributed application is created :-)
>>you can read more about it at:
>>http://www.extreme.indiana.edu/xgws/xsul/XSUL_Overview/
>>(in particular look on last slide where i show how JDK 1.5 can be used
>>to have really nice DII in WSIF style working in XSUL)
>>
>>
>
>I read your presentation on XSOAP4. It sounds really intriguing!
>
thanks!
> The last
>slide on DII makes it look easy to do dynamic invocations. Can the result
>contain complex types?
>
yes. i have XML infoset API that allows incremental mapping: you start
with XML element tree and map any children of it to Java objects. it
they can not be mapped you get simply hold on original XML.
>Also, one of the big things I like about WSIF is the
>hiding of the type of service. Will XSOAP4 support other types of services,
>such as those based on EJB, JMS, etc? I guess the correct term in WSIF-speak
>would be 'bindings'.
>
>
the code that is actually doing work is called 'provider' in WSIF-speak :-)
>I really like how easy it seems to do digital signatures on each end. I'm not
>even sure how to do that with AXIS,
>
there is already project to do this for AXIS called WSS4J see
http://sourceforge.net/projects/wss4j/ (WSS4J provides AXIS handlers
dsig work easy and comes with examples)
>but your api makes it look so simple.
>
>
i used dsig as example of how to implement an WS related aspect directly
with code without need to use WSDD or processing chains.
i think that as WS matures there will be need to add more aspects and
making easy to work with such code (maintenance, customization, amount
of code and number of files/abstractions, and debugging!!!!) is a real
challenge.
>It's a requirement I'll likely need. Perhaps your toolkit would better suit
>my needs :) Any more info?
>
>
we use it for all kinds of stuff so over time when it stabilizes i will
make it available probably around time when JDK 1.5 reaches beta so i
can take advantage of all syntax sugars and other niceties such as
generics and for-each loops ...
>I used AXIS a long time ago to do simple database work such as sending a query
>to the service, and having it send back the data as data transfer objects
>which were then converted into the appropriate domain objects via reflection.
>The complex types weren't known at the time the service was invoked, so
>that's why I resorted to using DTOs. I suppose I could have created more
>fine-grained services and would know the actual object types at invocation
>time, but that would be a large number of services. As I think back, the
>generic approach was pretty simplistic, but perhaps more fine-grained
>services would have been better. That would reduce/eliminate the use of DTOs
>as well as the overhead of converting the light-weight DTO objects into
>domain objects. It might also have made security easier. However, a generic
>approach would probably still be needed for dynamically generated queries.
>
>
you can use also toolkits such as castor or xml beans
(http://xml.apache.org/xmlbeans/) to bind XML infoset to Java beans
generated from XML schema.
>I've been using Richard Hall's Oscar OSGi Framework implementation, which is
>available at: http://oscar-osgi.sourceforge.net/ The Oscar mail list
>activity is quite small, but I think that it's because it's also quite stable
>:) Richard has an excellent tutorial on his web site which walks you thru a
>number of examples. The tutorial is a great way to get up to speed with
>OSGi.
>
>
i am just reading it - it looks good.
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Status update
Posted by Eric Swindell <er...@att.net>.
> i think it is pretty stable.
That is good to hear!
> so i wanted something that in its core is very modular to allow true
> plug&play or in OO words a toolkit that makes it easy to create and use
> web service by combining and extending existing modules. that is exactly
> how i designed XSOAP4. its alternative name is XSUL which stands for XML
> Services Utility Library and that is its philosophy: lot of pluggable
> modules.
Since I've been doing a lot of coding with OSGi services lately, I'm really
into the 'pluggable' mindset as well where the interface drives the car
instead of the implementation. Of course, extending existing implementations
which meet one's needs is great too, and increases code reuse. You can think
of an OSGi Framework as a kind of mini application services kernel ( hey, it
might not be the official techno-speak, but it's one way to describe it ),
where you can have all kinds of services running in an dynamic environment in
which they may come and go, and get substituted with other comparable
services with the same interfaces. An application is merely a bunch of
components offerring and requiring services. Warning: playing with this
stuff can be quite addictive!
> you can read more about it at:
> http://www.extreme.indiana.edu/xgws/xsul/XSUL_Overview/
> (in particular look on last slide where i show how JDK 1.5 can be used
> to have really nice DII in WSIF style working in XSUL)
I read your presentation on XSOAP4. It sounds really intriguing! The last
slide on DII makes it look easy to do dynamic invocations. Can the result
contain complex types? Also, one of the big things I like about WSIF is the
hiding of the type of service. Will XSOAP4 support other types of services,
such as those based on EJB, JMS, etc? I guess the correct term in WSIF-speak
would be 'bindings'.
I really like how easy it seems to do digital signatures on each end. I'm not
even sure how to do that with AXIS, but your api makes it look so simple.
It's a requirement I'll likely need. Perhaps your toolkit would better suit
my needs :) Any more info?
I used AXIS a long time ago to do simple database work such as sending a query
to the service, and having it send back the data as data transfer objects
which were then converted into the appropriate domain objects via reflection.
The complex types weren't known at the time the service was invoked, so
that's why I resorted to using DTOs. I suppose I could have created more
fine-grained services and would know the actual object types at invocation
time, but that would be a large number of services. As I think back, the
generic approach was pretty simplistic, but perhaps more fine-grained
services would have been better. That would reduce/eliminate the use of DTOs
as well as the overhead of converting the light-weight DTO objects into
domain objects. It might also have made security easier. However, a generic
approach would probably still be needed for dynamically generated queries.
> what is good web site to learn quickly about benefits of OSGi? what is
> URL for OSGi website ? is it http://www.osgi.org/?
I wish OSGi got more publicity. That's the correct official website URL. You
can download their latest specification from there, which is useful reading
if you want to understand OSGi service development.
I've been using Richard Hall's Oscar OSGi Framework implementation, which is
available at: http://oscar-osgi.sourceforge.net/ The Oscar mail list
activity is quite small, but I think that it's because it's also quite stable
:) Richard has an excellent tutorial on his web site which walks you thru a
number of examples. The tutorial is a great way to get up to speed with
OSGi.
Oh, 'ServiceBinder', from his other project at sf.net, gravity, is also
explained in the tutorial, which makes it easier to abstract out OSGi
specific api code from your code via xml descriptors, and have ServiceBinder
manage the services' lifecycles via IoC.
Eric
Re: Status update
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Eric Swindell wrote:
>Didn't you create the XSOAP API or the pull parser it uses?
>
both :-)
>Do you think there would be any performance benefits of having wsif use your API instead
>of Axis, and if so, have you done such integration?
>
i think that this is a deeper issue crosscutting both performance,
usability and interoperability i.e. performance is not for free.
>I haven't had the chance
>yet to use wsif or XSOAP, but plan on investigating both soon. I'd be
>interested in your thoughts in such integration possibilities.
>
>
if you like AXIS you should stay with it *unless* you have very serious
problems (and most of problems can be fixed either by code tweaking or
faster machines!) as AXIS is de facto standard SOAP toolkit for Java.
i believe that as XML and SOAP define what goes on the wire so it is
still possible to use different toolkits. i think that entry barrier is
not high. so if you have requirements to use SOAP toolkits that may be
better suited to your needs then i would just do it. that is exactly my
motivation for XSOAP4 (that will soon replace XSOAP1) - see below on my
angle on SOAP toolkits.
>I can only assume that the wsif api is rather stable due to the limited
>activity in this list :)
>
>
i think it is pretty stable.
>I'm also curious what you're using wsif for since it looks like your extreme
>lab is doing a lot of research. I like the fact that you can abstract out
>the type of service ( e.g. local POJO, web service, JMS, EJB etc. ) via WSDL
>so that these services essentially become 'pluggable' without the client code
>having to know the implementation details.
>
i am rather unhappy with complexity of current SOAP toolkits and
particularly their monolithic structure. i think WSIF is a first good
step in direction of pluggable WS toolkit though currently WSIF
providers are hopelessly mingled together and it is not possible without
a lot of work to compile a subset of WSIF providers.
the other limitation of WSIF that it is only client side API and
sometimes it is good to have pluggability also on server side. lack of
server side support led to very complicated and twisted tricks to get
async transports such as JMS to work to correlate incoming messages in
WSIF ...
so i wanted something that in its core is very modular to allow true
plug&play or in OO words a toolkit that makes it easy to create and use
web service by combining and extending existing modules. that is exactly
how i designed XSOAP4. its alternative name is XSUL which stands for XML
Services Utility Library and that is its philosophy: lot of pluggable
modules.
you can read more about it at:
http://www.extreme.indiana.edu/xgws/xsul/XSUL_Overview/
(in particular look on last slide where i show how JDK 1.5 can be used
to have really nice DII in WSIF style working in XSUL)
>I'm using OSGi services locally
>for such dynamic behavior, and would like to utilize wsif and/or XSOAP for
>remote method invocation / messaging.
>
>
what is good web site to learn quickly about benefits of OSGi? what is
URL for OSGi website ? is it http://www.osgi.org/?
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Status update
Posted by Eric Swindell <er...@att.net>.
Alek,
Didn't you create the XSOAP API or the pull parser it uses? Do you think
there would be any performance benefits of having wsif use your API instead
of Axis, and if so, have you done such integration? I haven't had the chance
yet to use wsif or XSOAP, but plan on investigating both soon. I'd be
interested in your thoughts in such integration possibilities.
I can only assume that the wsif api is rather stable due to the limited
activity in this list :)
I'm also curious what you're using wsif for since it looks like your extreme
lab is doing a lot of research. I like the fact that you can abstract out
the type of service ( e.g. local POJO, web service, JMS, EJB etc. ) via WSDL
so that these services essentially become 'pluggable' without the client code
having to know the implementation details. I'm using OSGi services locally
for such dynamic behavior, and would like to utilize wsif and/or XSOAP for
remote method invocation / messaging.
Eric
> Tim Williams wrote:
> > What is the status of WSIF?
>
> it is pretty stable.
>
> > Has development stopped or are there plans for the future...?
>
> AFAIK there is no any release plan.
>
> are there any features that you are interested to see in WSIF?
>
> thanks,
>
> alek
Re: Status update
Posted by Tim Williams <ha...@hotmail.com>.
I've had quite a hard time selling WSIF to colleagues. I think it is
because they just don't 'get it'. However, those that have realised what it
is all about are more than keen to exploit it and know a lot more about it
than I do. People seem to get as far as Web Services and stop there - such
a shame. Interest often stops when people ask what are the future plans or
how much activity is there.
I just subscribed to this list to find out what's [not] going on. Why are
bug fixes sitting in the repository with no release planned? A bit
worrying.
Still, this won't stop me from using it for now.
A second question - for the list though :-
Would anybody care to comment on the performance of WSIF?
Tim.
----- Original Message -----
From: "Eric Swindell" <er...@att.net>
To: <ws...@ws.apache.org>
Sent: Saturday, January 17, 2004 1:25 PM
Subject: Re: Status update
Thanks Tim.
I've been shadowing this list for quite some time and haven't made the time
to
start working with wsif. However, I'll be investigating its use quite soon.
I'd sure be interested in any details you or other folks have regarding
implementations or other experience.
As far as the bugs, at least we have access to the source :)
As far as alternatives, I'm not aware of any. It has a lot of benefits and
you'd think that many more folks would be interested in using it, but you
can't tell from the activity on the list.
Eric
> Not exactly...
>
> One on my colleagues has taken a great interest in WSIF, but he has had to
> use the latest build rather than the latest release because of a number of
> bugs that exist in the latest release. Even then he needed to either fix
> or implement a couple of things himself.
>
> I'll get some more details and post them. Ideally we don't want to use
our
> own hybrid version but there seemed to be little activity that was taking
> WSIF forward. This made me think there was some alternative that we
> weren't aware of.
>
> Tim.
>
> ----- Original Message -----
> From: "Aleksander Slominski" <as...@cs.indiana.edu>
> To: <ws...@ws.apache.org>
> Sent: Friday, January 16, 2004 10:03 PM
> Subject: Re: Status update
>
> > Tim Williams wrote:
> > > What is the status of WSIF?
> >
> > it is pretty stable.
> >
> > > Has development stopped or are there plans for the future...?
> >
> > AFAIK there is no any release plan.
> >
> > are there any features that you are interested to see in WSIF?
> >
> > thanks,
> >
> > alek
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
Re: Status update
Posted by Eric Swindell <er...@att.net>.
Thanks Tim.
I've been shadowing this list for quite some time and haven't made the time to
start working with wsif. However, I'll be investigating its use quite soon.
I'd sure be interested in any details you or other folks have regarding
implementations or other experience.
As far as the bugs, at least we have access to the source :)
As far as alternatives, I'm not aware of any. It has a lot of benefits and
you'd think that many more folks would be interested in using it, but you
can't tell from the activity on the list.
Eric
> Not exactly...
>
> One on my colleagues has taken a great interest in WSIF, but he has had to
> use the latest build rather than the latest release because of a number of
> bugs that exist in the latest release. Even then he needed to either fix
> or implement a couple of things himself.
>
> I'll get some more details and post them. Ideally we don't want to use our
> own hybrid version but there seemed to be little activity that was taking
> WSIF forward. This made me think there was some alternative that we
> weren't aware of.
>
> Tim.
>
> ----- Original Message -----
> From: "Aleksander Slominski" <as...@cs.indiana.edu>
> To: <ws...@ws.apache.org>
> Sent: Friday, January 16, 2004 10:03 PM
> Subject: Re: Status update
>
> > Tim Williams wrote:
> > > What is the status of WSIF?
> >
> > it is pretty stable.
> >
> > > Has development stopped or are there plans for the future...?
> >
> > AFAIK there is no any release plan.
> >
> > are there any features that you are interested to see in WSIF?
> >
> > thanks,
> >
> > alek
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
Re: Status update
Posted by Tim Williams <ha...@hotmail.com>.
Not exactly...
One on my colleagues has taken a great interest in WSIF, but he has had to
use the latest build rather than the latest release because of a number of
bugs that exist in the latest release. Even then he needed to either fix or
implement a couple of things himself.
I'll get some more details and post them. Ideally we don't want to use our
own hybrid version but there seemed to be little activity that was taking
WSIF forward. This made me think there was some alternative that we weren't
aware of.
Tim.
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ws...@ws.apache.org>
Sent: Friday, January 16, 2004 10:03 PM
Subject: Re: Status update
> Tim Williams wrote:
>
> > What is the status of WSIF?
>
> it is pretty stable.
>
> > Has development stopped or are there plans for the future...?
>
> AFAIK there is no any release plan.
>
> are there any features that you are interested to see in WSIF?
>
> thanks,
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
Re: Status update
Posted by Tim Williams <ha...@hotmail.com>.
OK, so I haven't done very well following up on this.
There are a number of bugs on bugzilla, some of which have been fixed and
can be obtained by using the nightly builds. Why not schedule a release if
there are recorded bugs that have been fixed. This seems particularly
strange.
Second up relates to Axis, and I'm not too clear on the details here but
there is a critical piece that only works with Strings and WSIF has support
for byte arrays, so one of the two has to be changed. (sorry this is so
vague)
Tim.
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ws...@ws.apache.org>
Sent: Friday, January 16, 2004 10:03 PM
Subject: Re: Status update
> Tim Williams wrote:
>
> > What is the status of WSIF?
>
> it is pretty stable.
>
> > Has development stopped or are there plans for the future...?
>
> AFAIK there is no any release plan.
>
> are there any features that you are interested to see in WSIF?
>
> thanks,
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
Re: Status update
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Tim Williams wrote:
> What is the status of WSIF?
it is pretty stable.
> Has development stopped or are there plans for the future...?
AFAIK there is no any release plan.
are there any features that you are interested to see in WSIF?
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay