river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: River & OSGi
Date Thu, 19 Nov 2009 05:23:54 GMT

Sent from my iPhone

On Nov 18, 2009, at 8:59 PM, Sam Chance <sgchance@gmail.com> 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  

> Sam
> On 11/18/09, Mike McGrady <mmcgrady@topiatechnology.com> 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 <sgchance@gmail.com> 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 <mmcgrady@topiatechnology.com> 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,
>>>>>>> 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
>>>>>>> the
>>>>>>> database data, would consume significantly less network
>>>>>>> resources.  EG
>>>>>>> the data transferred over the network is reduced by a factor
>>>>>>> 100 by
>>>>>>> processing the data on the database machine after querying. 
>>>>>>> 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
>>>>>>> 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",
>>>>>>> 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
>>>>>>>>> entire JVM,
>>>>>>>>> then restarting.  At least OSGi allows you to stop a
>>>>>>>>> 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
>>>>>>>> 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
>>>>>> mmcgrady@topiatechnology.com
>>> --
>>> 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)

View raw message