sounds intriguing!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.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 :-)
thanks!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?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
