My Apologies for the type, it was Michael Warres who is credited with
codebase services.
Peter Firmstone wrote:
Michael McGrady wrote:
Peter,
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.
You've got a point there, they're definitely different, with disparate
scope, yet each implementation solves their problem elegantly in
similar fashion. I was naively hoping to avoid the difficulties of
earlier discussions had with confusion between Jini Services and OSGi
Services, but like you point out be careful of generalisations.
Perhaps the best way to communicate is with code.
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.
That's what I was thinking, first make all the versioning information
available in metadata. The first potential OSGi service I can see is
for the net.jini.security.policy.DynamicPolicyProvider.
I'm currently reimplementing DynamicPolicyProvider for concurrency, in
doing so however it creates a dependency on Java 5. I'd like to keep
the earlier implementation for memory constrained or embedded
environments such as Java 1.4 SE or cdc. So the DynamicPolicyProvider
would be a good start. Although I'm currently doing this using
ServiceLoader SPI.
Currently all jar class file dependencies in River are identified at
build time using ClassDep. This was recently reimplemented using ASM,
building upon code donated by Tim Blackman. It was during
reimplementation that I started asking questions, thought about jini
codebase services, discovered Michael Warren had already done this and
had some brief email discussions with Tim Blackman about ClassLoader
trees, for maximising sharing of compatible classes, identification of
Class API signatures and hence Package API. I think that one of most
important findings Tim made was that bytecode SHA-1 hashcodes differ
between java compiller implementations and optimisations. I can see
that the harvesting metadata from static analysis will be relatively
straight forward to implement. Think of it as reflective metadata,
I'd like it to be available from the jini codebase service along with
Package version metadata from bundles to ensure at the very minimum
API compatible classes are loaded. It'd be ideal if developers could
upload their bundles to jini codebase services which perform the
static analysis and publish the metadata. The metadata can also be
used to check potential security issues of permission grants to third
party bundles.
The reason I believe the Package API signatures are important is that
as software evolves over time, developers cannot know that future
versions of libraries or code will remain compatible.
Most software only depends upon a subset of a library's public API, it
is very likely that API changes won't break compatibility with all
dependant software. What is more important is that incompatible
Package implementations are not allowed to interact and break at runtime.
While reducing memory consumption by reducing package duplication ( in
the case of OSGi unnecessary bundle duplication) will be of some
benefit it is more important for domain data objects to be shareable
and visible between compatible implementations when they're supposed
to be.
A major importance of jini codebase services is the removal of the
dependency of byte code on its URLClassloader origins. Especially for
disconnected services and unmarshalling of persistent Marshalled
Object data, originated from extinct services.
The part I'd like to figure out is how to utilise Jini Codebase
Services, the Exported Package API signature metadata and the
Dependency Import Package API signature metadata within OSGi. Because
ultimately my main aim is to enable cooperation of code between
disparate systems separated by distance and domain.
Cheers,
Peter.
I hope this is helpful and thank you for stating what you were thinking.
Mike
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 the
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 latter.
Mike McGrady
Principal Investigator AF081-028 AFRL SBIR
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
[email protected]
