> >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
