Re: River & OSGi

Thu, 19 Nov 2009 06:37:43 -0800

First, Peter, I wish you the best in your struggles with your health. I know what you mean about letting work absorb you: it keeps us present when we fall into it.
Second, sometimes people take my questions as answers when they are questions. I meant the question about class genuinely and not in some passive aggressive sense. OSGi works with managing URL classloaders so I wanted to get clear about what was meant about classpath. 


Third, people tend to identify personally with things that then become  
sensitive to them.  I tend to try and stick to the subject .



Obviously under those conditions it does not work.  I am too serious  
about the topic many times to take the time to be careful about the  
egos involved, including mine.  Often i have just have a minute.


So these venues are probably not the best for me.

Thank you for your assistance.

Sent from my iPhone

On Nov 19, 2009, at 2:35 AM, Peter Firmstone <[email protected]> wrote:


My last point was about not letting the little things get to you,  
don't argue the little things, just suggest another way if you don't  
like it.



For example, your last comment to me that I haven't gotten around to  
answering is :


What is "the classpath" here?  You cannot mean the Java classpath.

Could have been rephrased as:


I see your setting the classpath to load classes from for your  
dependency analysis, you know tool xyz can help you do this better.   
And let the programmer go off and investigate the rest, 9 times out  
of 10 they'll be grateful.



If it is a misunderstanding, it doesn't matter as it has the  
appearance of assistance and is non threatening.



I might have come off the wrong way with my last comment.  You may,  
or may not be aware,  I'm receiving treatment for a brain tumor and  
have had some bigger picture issues to deal with in recent months.


The reason I'm still putting in an effort on this project is:

1.  I still believe Apache River and Jini to hold the key to  
pervasive computing and I'd like to see the project reinvigorated  
and succeed.
2.  It occupies my mind so I can stay positive and not let life's  
difficulties get me down.



I had prepared an answer for your question earlier so I'll post that  
for you.


Peter.

Mike McGrady wrote:

I'm probably not made for these lists.  Maybe I should just keep my  
opinion to myself.  I consider myself an expert in the field on  
some topics and don't have months to go through what I consider to  
be the standard misconceptions.




Sent from my iPhone


On Nov 18, 2009, at 11:13 PM, Peter Firmstone <[email protected]>  
wrote:



Mike you need to stop sounding like your looking down from the top  
of the podium and adopt a little humility in your comments.  Do  
try to be a little more agreeable.  Otherwise it rubs people the  
wrong way, which just isn't productive.  If your on the run all  
the time, perhaps you might want to get a netbook instead of the  
iPhone, then you can open an ide too.  Much better for  
participating.



I think that what comes across as an attitude of I know better and  
your wrong (whether intended or not) on the dev list is what puts  
people off participating.  Nobody wants to argue the details, we  
want to feel like we're contributing something.  We need to  
encourage people to try, perhaps we can set up an experimental  
area for would be committers, if need be, so they gain confidence  
to participate, more knowledgeable people can have a look and make  
suggestions and assist.  Once you start to get to know the  
codebase it isn't that hard to work with, I've been creating jUnit  
tests from the integration test code when I make changes to a  
class, it's pretty easy to do in your ide and the test results are  
instant.  Every now and then you can run the integration and jtreg  
tests.



I downloaded your code from svn on kharma, have had a brief look  
and plan to look into it further, while doing so I thought to  
myself, here is someone who can write code,  why are we having so  
much trouble communicating?



You know when I talk to the great coders, their attitude is never  
one of superiority, it's always one of generosity and assistance,  
they're just happy to help with whatever problem your  
experiencing.  I think that's what distinguishes the great  
programmers, communication, it is reflected in their code too, and  
I'm not talking about comments, I mean you read the code, the  
names of methods and classes, the intent is just obvious.  But  
then look on find bugs, even the best are still human.



One word of advise about life, once you realise your own mortality  
and stare death in the face, before your time, especially when you  
have children, you wont worry so much about the technicalities,  
the little things just don't bother you anymore.  Make the most of  
life while it lasts, it really is fleeting.  It's not what you  
have that matters, its who.  Everything we argue over today will  
be forgotten tomorrow.


Best Regards,

Peter.



Mike McGrady wrote:



Sent from my iPhone

On Nov 18, 2009, at 8:59 PM, Sam Chance <[email protected]> wrote:


Mike,


The typos and comments in your "reply" suggest you may be tired  
or a

little under "some" influence.



I am using an iPhone and haven't taken a single intoxicant for  
millenia.  iPhones make up there own spelling at times.





If your "SOA experience" is typical, I can almost guarantee that  
it

consists of proliferating (SOAP-based) web services...so what?
Wrapping an interface in XML simply perpetuates the same brittle -
point-to-point - architecture.


This is not true for real systems.




As for SLA, you *must* be joking! SLA are one of the *missing*  
aspects
of "mainstream" SOA. In fact, only recently has SLA been  
elevated in
the dialog. I'm quite confident the "weighty SOA mindset" you  
posit is

based on WS-*.



You are clearly confident but mistaken.  Try to get SDN data for  
the FAA SWIM program your way.  Knowing about the data has  
virtually nothing to do with actually getting it.





I find it almost humorous that you seem to refute Jini and OSGi as

instances of SOA constructs. You may want to circle back and  
change

all the literature about these two SOA frameworks to reflect your
view. Good luck with that.



SOA is not a framework.  SOA is an architecture in which the  
atomic elements are business level services.  This is standard  
talk.





I live and work in the DC area. I sense you do as well; or at  
least
you work on DoD or Federal government systems. That would  
explain your

view about "SOA". But I could be wrong.


I dont live in DC.  I live in the Seattle area.





I'd welcome the chance to meet with you and hammer out these  
issues.
I'm sure I could learn a lot...and *maybe* teach you a thing or  
two.

:-)



I am sure I could learn a lot from you.


If you want to see SLA implemented by the runtime in a policy and
model-driven way, look at the Paremus Service Fabric. (Seems like
groundhog day...again).



Service level agreements are not implemented in code.  This is  
WHY SOA works.




Sam


On 11/18/09, Mike McGrady <[email protected]> wrote:

I have been involved with some fairly mature and well known SOA

systems for years and I certainly would never consider either  
Jini or

OSGi to be anything remotely like a SOA netwrk.  SOA services are
explicitly SLA based and defined by business rules outside any IT
strictures.  That is the key to there success.


Only in a general and inconsequential sense can OSGi be  
considered to

have a registry.  Keeping syst state is not a registry.

I wish this conversation, since it diverges willy milky from

established computer science terminology could stuck to the  
particulars.


Just my thing and I probably have nothing more to say.



Sent from my iPhone


On Nov 18, 2009, at 5:14 PM, Sam Chance <[email protected]>  
wrote:



Peter,


I agree with the notion that Jini and OSGi both implement the  
publish,
find and bind interaction model/pattern/paradigm / whatever  
additional
related words one prefers. I've always described this  
construct as the
"operational model" of SOA. It is exceedingly obvious to even  
the most

casual observer that Jini and OSGi adhere to this. The essential

difference is - in general terms - OSGi implements "publish- 
find-bind"
in a local memory space (I.e. a JVM) and Jini implements this  
across
multiple memory spaces (I.e. distributed). In my view, it is  
precisely
this difference that yields the complimentary nature of the  
two [SOA]

frameworks.


Ironically, although contemporary mainstream SOA  
"deployments", which
are arguably Just a Bunch Of Web Services (JBOWS), prescribe  
'publish,
find and bind', they rely little on a registry (e.g. UDDI) for  
the

'find' function. Instead, they achieve the 'find' function via a

highly distributed and decentralized mechanism called  
"WoM" (Word of

Mouth). :-)

Sam



On 11/18/09, Michael McGrady <[email protected]>  
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.


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.

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]

















--
Sent from my mobile device

Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)




--
Sent from my mobile device

Sam Chance
443-694-5293 (m)
410-694-0240 x108 (o)































					Reply via email to