river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <mmcgr...@topiatechnology.com>
Subject Re: River & OSGi
Date Wed, 18 Nov 2009 12:05:30 GMT

Okay.  I see.  You are not using "pattern" in the sense of pattern brought into computer science
by the Gang of Four.  You are using that term more in a plain English sense.  I think this
is misleading in this venue and would suggest that you use another word to avoid the possible
misunderstanding that you meant "design pattern" as it is used in computer science.

On a more substantial note, I don't think the "pattern" you discuss is the same at all for
Jini and OSGi.  The services for OSGi are not like the services for SOA.  SOA services may
or may not be akin to the services for Jini.  I am very careful about abstracting or generalizing
because, although my first and last love in computer science is architecture, the devil is
in the detail.  

For my part, I think it would be worthwhile to determine the level of Ossification you want.
 For example, there would be no harm at all in seeing whether you can modularize the jar files
into bundles.  Once that is done, then you can begin seeing how the actual processes in OSGi
match those in Jini.  As yet, you do not even know, as I understand it, what OSGi services
you want.  That would need to be determined, since you will be customizing them.

I hope this is helpful and thank you for stating what you were thinking.


On Nov 17, 2009, at 8:33 PM, Peter Firmstone wrote:

> Mike McGrady wrote:
>> I am presently the author of a framework called "Karma" (Kolona Automated Resource
Management Architecture) that is open source with a management app under another open source
framework AUM (Automated Universal Middleware).
>> UM  (Universal Middleware) is a more current name for OSGi.
>> We could have called it DUM (Distributed Universal Middleware) instead of AUM but
thought better.
>> Too bad we did not get on better when I asked you what you meant by "Service Pattern".
 (I still have no idea what you mean.)
> Here's a Clarification of what I meant by "Service Pattern", from Richards Book, page
12, this should clear up any remaining confusion:
> "the service-oriented publish, find, and bind interaction pattern: service
> providers publish their services into a service registry, while service clients search
> registry to find available services to use (see Figure 1.3)."
> So there you go it's the "Publish, find and bind interaction pattern"
> The point I was attempting to make in the beginning was that Jini, OSGi, ServiceLoader
and Netbeans Modules all use the "Publish, find and bind interaction pattern" to solve different
problems, I was trying to lay out the understanding to avoid an argument and promote a discussion
about how to implement utilisation of OSGi within River and its applications.
> I still haven't managed to achieve this discussion, hopefully the best way forward will
become more apparent during implementation.
> Cheers,
> Peter.
>> Anyway, this does all you want to do and we have a plan to have it set as a standard
with IEEE, where I am a member of the standards committee.  If you check there in a few months,
you can see what I was hoping to talk to you about before your ego got in the way.
>> Good luck with your endeavors.
>> Mike
>> On Nov 8, 2009, at 5:06 PM, Peter Firmstone wrote:
>>> Yes that's the beauty of Services, they provide opportunity for pluggable replacement
implementations.  That's the "Service Pattern"  As we have seen it is possible to use the
Service Pattern to solve a number of different problems.  Eg Netbean Plugins, SPI, OSGi, Jini.
>>> I'm looking at OSGi to wire up services inside the JVM as you say.  When I say
package, I mean a java package residing in the local JVM it may or may not be part of a Jini
service, it may be a purely local JVM package, eg a library dependency or local domain package.
 For example, I have package X, version 1 loaded in my local JVM, I need to have package X
version 2 loaded as version 1 isn't compatible with the new Objects (domain data) I'm recieving
in serialized form.  I need to share this information locally with Package Y that currently
has references to objects in Package X version 1.  The Objects in Package X version 1 that
Package Y references need to have their class files upgraded.  Without OSGi I can do this
by persisting state, stopping the JVM, restarting and loading package X version 2.
>>> I'm not looking at distributed OSGi, but I can see a use case for utilising a
Jini Service, when a local OSGi bundle that performs some task that could be done optimally
if the processing can be moved to where the data resides, this is just an example there are
probably 10 other ways of doing this:
>>> A local application bundle that provides an OSGi service locally queries a remote
database using JDBC and performs a considerable amount of manipulation to that data prior
to returning a subset.  The query and its result are sent over the network using a database
JDBC connection.
>>> The processing for that data, if shifted to the machine that has the database
data, would consume significantly less network resources.  EG the data transferred over the
network is reduced by a factor of 100 by processing the data on the database machine after
querying.  A bundle that provides a "local JVM application" an "OSGi service" could utilise
a "Jini Service" to request the data be processed at the Database machine in a particular
manner before receiving the result.  This function could be locally available as an OSGi service
to some other local application, that application doesn't need to know about Jini, it is an
implementation detail that is abstracted.
>>> My objectives are all based around codebase services (objects aren't locked to
their http codebase origin), in combination with OSGi or something like it, to ensure compatible
classes and packages are loaded among separate JVM instances.  Yes Newton does something similar,
however it is AGPLv3 licensed.
>>> I envision a distributed environment where nodes can have the majority of their
packages downloaded and upgraded via codebase servcies. Providing an evolving cluster, that
upgrades it's bundles incrementally, while maintaining the maximum level of class and package
compatibility.  Think Agile Cluster Running System component upgrades.
>>> People, who are jumping in now because I've mentioned OSGi, are making assumptions
and haven't been following the discussions I've posted previously about Versioned Classes,
Classloader trees, Static Analysis and Codebase Services, this is frustrating as I was hoping
for some participation.  It seems I can only get attention when I mention a controversial
subject.  What I want is attention to solving the problems that will make River better.
>>> In my note below when I'm referring to the "Service Pattern", I mean the service
pattern that OSGi implements, enables bundles to be upgraded by loading the replacement bundle
in a new classloader,  The service is a common interface, the new upgraded service is discovered
after it is started.  The alternative is to use delegates to update references between objects
when the Classloader changes as per some of the other patches I've uploaded.
>>> Jini also utilises a "Service Pattern", but to solve a different problem.
>>> I knew this was going to be a difficult topic to present.
>>> What we need are separate lists, where people who want to participate in constructive
development to solve problems can do so and another list where people can pontificate about
software ideals and have disrespectful arguments with each other without holding up development.
 While we're developing we can keep an eye on the argument list without getting embroiled.
>>> Anyway I've said enough, I'm going back to doing the things I need to do, if
someone who has been following my posts to date has implementation ideas, but are afraid to
mention it, please feel free to contact me directly to discuss, I do need some input to gain
confidence that I'm approaching these problems in the right manner.
>>> Peter.
>>> Dennis Reedy wrote:
>>>> On Nov 8, 2009, at 1251AM, Peter Firmstone wrote:
>>>>> I had avoided OSGi purely due to the controversy it generates on this
list, however without the Service Pattern one cannot upgrade a package without first persisting
everything and shutting down the entire JVM, then restarting.  At least OSGi allows you to
stop a bundle and any dependents, persist what you need to then start with a later bundle
version if desired, without having to persist or shut down the entire JVM.
>>>> If thats all you want you dont need OSGi. Service lifecycles are supported
with a variety of container approaches, from JEE, Spring to Rio. You also do not need to shutdown
the JVM to load new service classes.
>>>> Adopting OSGi as a micro-kernel architecture for wiring up services inside
the JVM is a different thing. Looking at distributed OSGi is a totally different thing on
top of that. IMO, if you want to consider OSGi for River, you focus on the former, not the
>> Mike McGrady
>> Principal Investigator AF081-028 AFRL SBIR
>> Senior Engineer
>> Topia Technology, Inc.
>> 1.253.720.3365
>> mmcgrady@topiatechnology.com

View raw message