> 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
