A Conversation: was Split JINI

[Michael McGrady <mm...@topiatechnology.com>]

Read at your peril.


On Dec 23, 2008, at 1:17 PM, Gregg Wonderly wrote:

> Michael McGrady wrote:
>>> For Java software, the JERI stack codified in River, provides the  
>>> ability to plug in the needed invocation details (starting at the  
>>> BasicILFactory point). The Exporter allows this invocation layer  
>>> and an endpoint technology and security constraints to all be  
>>> unified into a single point that allows them to be plugged  
>>> together and arranged to work as needed.
>> My question was what if WINI, XINI, YINI and ZINI were Java?  If  
>> so, JERI would not be involved, for example.
>
> You didn't indicate whether any of these where remote or local, has  
> classloading capabilities etc.  Each layer of the Exporter- 
> >InvocationLayerFactory->Endpoint chain provides a unique point to  
> couple into the JERI "stack".  Technically, Exporter is not in the  
> JERI stack, but I consider it as part of the stack because for a  
> service, it provides the first layer in how a service interfaces  
> with clients.
>
> If you want to export a JavaSpace, without JERI  
> (InvocationLayerFactory plus Endpoint), then technically, you can  
> provide outrigger an Exporter, in the Configuration, which does  
> whatever you want through the Exporter.export() returned "proxy".   
> It could use whatever it wanted.  I've done this to use MODBUS as  
> the interface to a device.
>
> But, if you want to take advantage of more of the infrastructure  
> that JERI provides, then you should code to the JERI interfaces and  
> use existing classes, such as BasicJeriExporter.

WINI, XINI, YINI and ZINI are competitors, not users, of JINI.

>
>
>>>>> Why?  Because the spec has semantics in it too, and those  
>>>>> semantics (like RMI call-by-value) need to be supported at the  
>>>>> Java interface level for a Java written Jini bit of software to  
>>>>> be compatible with other Jini bits of software.
>>>> But, is this good or not good?
>>>
>>> The specification of anything that is a standard narrows the path  
>>> for non-conformance or other forms of confusing that create the  
>>> need for "work arounds" or "better solutions".
>> Specifications sometimes are enhanced by creating as much non- 
>> conformance as possible.  You have to have MPEGs read one way but  
>> they can be written any way.  Standards should be as lean as  
>> possible to let innovation work.  Don't you agree?
>
> I believe in maximum specificity of what matters, and "generate  
> perfection", and "tolerate imperfection" as a basic premise to  
> software construction.

The problem is that that maximum specificity in matters of standards  
is not a virtue but a vice.  Minimum specificity is the goal.

>
>
>>>>> In the world of SOA, there are all these concepts, but they are  
>>>>> described independent of a technology, and they are honestly  
>>>>> more akin to "best practices" than they are as "architecture."
>>>> I definitely do not agree with this.  First, comparing SOA and  
>>>> JINI is comparing applies and oranges.  A SOA service is nothing  
>>>> like a JINI service.  SOA definitely, to my way of thinking, is  
>>>> an architecture.
>>>
>>> A Jini service is a service, plain and simple.
>> There is not such thing as a "service, plain and simple".  SOA is  
>> not a sudden discovery that there is such a thing as services.   
>> Services are as old as the hills and SOA is not.  The type of  
>> service in SOA does not predate SOA.  SOA services are defined by  
>> business people and those people do not have to know a single thing  
>> about technology to do that.
>
> I will concure that they can define that a particular type of  
> service is needed.  But, until it has one or more interfaces to its  
> users, it is just conversational interest because it is providing no  
> value.

Actually in SOA the interfaces are not that important.  One of the  
great things about SOA is the integration of disparate interfaces with  
using triangulate numerals as adapters.

>
>
>>> A Jini client is a client of a service, but may be a service itself.
>> A SOA service is a producer, a producer that encapsulates its  
>> state.  The SOA producer knows nothing about the consumers: SOA  
>> transactions are stateless.  Nothing means nothing.  The consumers  
>> also know nothing about the producer: they too are stateless.   
>> Nothing also means nothing here.
>
> Until a technology is applied that lets consumers have access, it is  
> just of conversational interest, and has no value.
>
> > There is an SLA that the system provides.  The system,

Do you not want to talk about SOA?

>
>> consequently, requires that integration logic be decoupled from the  
>> business logic.
>
> Something or somebody has to make the connection or neither can  
> participate in the system.

Yes.  How do you think that happens?  There are no connections from  
the business logic.  When you get what happens, I think you will see  
what I am saying.

> When that connection is made, a technology is employed.  At that  
> moment, there is value to be had.  I don't see how there is a  
> "requirement" that the integration logic be decoupled from the  
> business logic.

Then, Gregg, you don't understand SOA.  SOA is stateless at the  
service level, so there cannot be knowledge of one service, consumer,  
producer, etc. of another.

> What I know is that at deployment, the implementers of the service  
> had to have enough information about what choices might be made at  
> deployment to provide a software system that allows that to occur.   
> That would require them to choose specific technologies that allowed  
> the choices.

Still SOA is stateless and what you need to see is how different that  
is from JINI.  I do not mean JINI has no use in a SOA but it has  
nothing to do with a JINI service.

>
>
>>> Service Oriented Architecture includes no specification of  
>>> technology.
>> This depends on what you mean by "specification".  SOA requires  
>> that the communications be event-based.  That certainly has a huge  
>> impact on technology.
>
> There are lots of ways to get event based communications and I am  
> not sure that it's a huge impact, but it can drive the design of the  
> software system, as I said above.

Event-based communications also completely decouple integration  
logic.  There are four kinds of IT communications.  They are based on  
what values they have with respect to two attributes, viz., whether  
the consumer or the producer initiates the communication and whether  
the initiator of the conversation (producer or consumer) knows the  
address of the other one (consumer or producer).  An event-based  
communication is initiated by the producer and is unaware of the  
address of the consumer.  This is why SOAs are event-based.

>
>
>>> What this means is that you can talk about SOA all you want, and  
>>> in the end, that conversation is valueless in terms of solutions,  
>>> because it doesn't let anyone know how they might actually get  
>>> work done in such your SOA.
>> SOA is not a problem.  SOA is a solution.  So, talk about SOA  
>> certainly should have something to do with solutions.
>
> The solutions are discussed, but the actual value is unrealized  
> until they exist as consumable services.

The genius of SOA is exactly the opposite of what you are saying.

>
>
>>> They might discern that you have particular types of services,  
>>> they might learn that you've embraced various details of an SOA.
>> I don't understand this.  Not sure how you can talk about a SOA  
>> like this.
>
> SOA discussions, for me always go in this direction.  I'm a detail  
> person. There is no value in SOA until you talk about the  
> technologies that you will involve.

There is no value if you do.

> Only then can one see and understand the ramifications that each has  
> on the system.

The whole point is that whatever they are they do not have  
ramifications.

> By deferring the discussions of technologies, too long, you disallow  
> yourself the opportunity to understand the ramifications until  
> later. I fear that this will typically cause a lot more grief.  This  
> is probably more of my view of bottom up design, which I think is a  
> service oriented view, vs the old waterfall, top down design view,  
> which I think causes services to be mis-designed because the details  
> of a service are delayed too long.

The details in SOA are delayed forever in IT.  That is required.

>
>
> SOA, for me is a waterfall, top-down view unless you include  
> technologies in your view of how the system will function overall.

SOA is wholly unrelated to the technology.

>
>
> You can ignore technologies for a while.  But after a while,  
> technologies become the controlling factor in the success of your  
> implementation.  This, causes me to favor early consideration over  
> delayed commitment.

In my opinion, Gregg, you do not understand system architectures.  You  
think solely in terms of engineering and pretty much nothing I say  
will appeal to you.

>
>
>>> When the rubber hits the road, you have to decide on a technology  
>>> that provides the features of your SOA.
>> This too does not make sense to me.  Technologies have nothing to  
>> do with SOA features.  Those features are architectural and paper  
>> bound.
>
> Let's say that you have a business that has a summary item that  
> drives most of what happens.  As part of your SOA, you decide that  
> you need to have a summary service that will take all the inputs and  
> create the summary item needed.

SOA architectures are defined at the business level by  businessmen  
and women.

>
>
> You talked earlier about SLAs, so I'll guess that you'd like to  
> include an SLA in the description of the service.

The service really is the SLA.  Nothing else matters or is settled,  
ever, anytime.

> What else do you think needs to be included to understand how this  
> service would be used?

Nothing.

> Would we consider whether a database was a useful storage spot?

Definitely not.

> Would we consider whether the database interface for queries would  
> be the primary point of access, or would we talk about whether a web  
> interface is needed for human consumption?

No.  None of these.

>  Would we ask whether caching was important for speed?

No, just read the SLA.  That's it.

> Would we talk about whether the liveness of the cache would be a  
> push or query based refresh?

No.

> How much detail would you include?

None.

> The more detail you go into the more technology choices you expose  
> right?

No.  You don't do that.

>
>
>>> Some of those technologies might be things like pens, postit  
>>> notes, white boards, projectors, chairs, tables etc.  Which are  
>>> services to their users in that they allow certain tasks to be  
>>> carried out using the specific mechanical interfaces that they  
>>> provide.
>> This is totally unconnected to a SOA.
>
> No, an SOA has to include people tasks too.  If you don't include  
> human impact and interface issues, you've missed on the largest  
> factor of efficiency in your system.

You mean a service has to include these.  SOA is an architecture and  
not an system.

>
>
>>> But when you get into the realm of software, then you have to  
>>> decide what will be the pen (invocation layer), ink color  
>>> (marshalling technology) and paper (transport layer) of exchanges  
>>> between software bits.  These decisions dictate a lot of other  
>>> things about what the software can do with the other entities in  
>>> the system.  So, many people end up with a custom, combined  
>>> invocation layer and marshalling layer that hide SOAP/XML or  
>>> whatever technology they've decided on.
>> This all has nothing to do with SOA that I can see.
>
> This is where I think at.  This is why SOA is valueless to me.   
> Details are what matter and what make things actually work.  For me  
> this is the system architecture because communications is all that  
> matters in an SOA vs a single process system.  If you can't  
> communicate between services and users, there is no value in the  
> services existance.

You really don't understand what SOA is, Gregg.  You are talking like  
someone who says they don't give a damn about gravity because it is  
just a theoretical construct.  The questions are way, way, way deeper  
and more subtle tthan you are allowing for here.

>
>
>>> As soon as you do that, you've effectively wrote off all features  
>>> of the IL and marshalling that you don't expose in that layer.
>> How are we marshalling with SOA?  That does not make sense.
>
> Sometimes I guess services and users should communicate...  If your  
> SOA has no communication between services and users, that's fine,  
> but where is the value then?

Users subscribed to or register with services in a SOA.  You think  
that communication in IT means a connection between the parties to the  
communication.  That is only true half the time.  The other half you  
don't understand.  I suggest you take on some reading on event-based  
communications and anonymous request/reply communications.

>
>
>>> This is where Jini differs.  With Jini, that IL and marshalling is  
>>> completely at your control.  It has exact details specified in  
>>> simple terms.
>>>
>>> At the method layer:
>>> o    all methods throw RemoteException to indicate a problem in the
>>>    IL or endpoint mechanics.
>>> At the invocation layer:
>>> o    method values are passed by value always.
>>>
>>> There are other things about security constraints which can change  
>>> some of
>>> the types of RemoteException which will occur, but still, you get  
>>> a RemoteException.
>>>
>>> All of these we know will always be present in a Jini system.  So,  
>>> we can be very deliberate and very specific about how to deal with  
>>> the problems that can occur.
>>>
>>> > It
>> Yes, which means that it is totally antithetical to SOA, which does  
>> not mean it is worthless.  Just that it is different.
>
> Maybe you can explain to me what is not antithetical to SOA from  
> your viewpoint?  When you throw out these types of comments with  
> absolutely nothing behind it, it's very difficult to communicate  
> about the real issues.

Any distributed state.  The trouble here, I think, Gregg, is you don't  
have a lot and maybe hardly any exposure to architectural principles  
in software development.  This is not unusual.

>
>
>>>> means "Service-Oriented Architecture" which is not dispositive  
>>>> but is a strong hint or something has gone very wrong.  JINI is  
>>>> really not SOA oriented at all.  It has uses which really  
>>>> interest me but SOA is not one of them.
>>>
>>> Okay so with my explanation above of my view of Jini, how would  
>>> you clarify your view that Jini is not SOA "oriented".  What  
>>> features of Jini keep it from working as a client and service  
>>> creating technology?
>> Pretty much everything you said about JINI was confirmation that it  
>> is antithetical to a SOA service and the implied sorts of  
>> communications that must exist between consumers and producers that  
>> know nothing about one another.
>
> Jini service lookup is THE point of "knows nothing about one  
> another".  By using the discovery services, I can find ALL services  
> (not just ones implementing a particular interface).

We are talking applies and oranges here.  Yes, a lookup service should  
be decoupled from the applications it is used with, one of the reasons  
why I think JavaSpaces is primary to JINI.  Normally, however, a  
lookup service provides a reference.  We definitely don't want that to  
happen with a SOA service.

>
>
> There could be a WSDLEntry on a service if I wanted to advertise a  
> SOAP interface.  A proxy service could just look for all WSDLEntry  
> services, and provide the interface between my Jini service and your  
> SOAP enabled client.
>
> I also could just use Java introspection to find out about a service  
> and then utilize what is there.  But, that doesn't seem like much of  
> an architecture thing.  You said that you look at the interface  
> level.  If you have a Java interface, then you have lots of choices,  
> because the implementation of that interface can be multifaceted to  
> include proxied services etc.
>
> Client Jini software can use things like ServiceDiscoveryManager to  
> not have to know how many of a particular kind of service exists, or  
> which one to use for the task at hand.  But, an architectural  
> decision has to be made about whether something is a singleton or a  
> multiple instance "service" so the client can utilize the  
> appropriate patterns.  To make that plugable still requires advanced  
> knowledge to make that possible.
>
> What I sense is that you really have a limited idea/concept of how  
> Jini relates to the solutions you need.  I'm more than happy to keep  
> plugging away at the gap, but I really am having a hard time given  
> the size of the gap that I perceive.

The problem is not the size, it is the nature of the understanding.   
SOA is completely orthogonal to your concerns.  I think I understand  
the basic architecture of JINI and I like it.

>
>
>>> The spec is what you should consider first.  That is the  
>>> behavioral description of what has to happen.
>> How so?
>
> It says things about why there are transactions and leases.  What  
> those mean in the system and how you deal with events related to the  
> lifecycle of those items for example.  The API javadoc might say  
> something more or less in line with the spec documents.  Over the  
> years, more spec has moved into the javadocs so there is more one  
> stop shopping.
>
>>> The interfaces, which exist today, are one way to do the things  
>>> that the spec details.  No other implementation has appeared with  
>>> a different API, so the net.jini stuff has sort of become what  
>>> some thing of as Jini.  I consider the net.jini interfaces to  
>>> represent a Java codification of the spec, but not necessarily the  
>>> only one.  It wouldn't be great to have lots of different version  
>>> of the same interface running around which supported the same spec  
>>> behavior, but used entirely different types etc.  So, certainly  
>>> the existing net.jini definitions of classes and interfaces are  
>>> what meet the spec and provide a portable platform.
>> The JINI spec is an end product.  I am interested JINI but am also  
>> interested in a little wider or higher view than the JINI spec.   
>> Interfaces are the leverage points in an architecture.  I am more  
>> interested in interfaces.
>
> The spec is the SOA level.  The interfaces are the technology behind  
> that.

No the spec is not at the SOA level.  Businessmen do not design JINI  
services based on the spec.
>
>
>>>>> The services in River are implementations of the spec.
>> I am not quite sure what an "implementation of the spec" would be.   
>> I do know what an implementation of an interface is.  I also know  
>> what compliance with a spec would be.
>
> There are both classes and interfaces detailed in the spec.  You  
> need to consider that interfaces have some behavior specified, while  
> classes have behavior implemented.  Outrigger is an implementation  
> of the JavaSpace specification and associated API.  It has behaviors  
> that are not tied to the spec.  For example the spec does not detail  
> storage of Entry objects, nor the performance of the storage  
> system.  Outrigger stores a copy of Entry objects in memory.  This  
> sets an upper limit on the total number of items that can be  
> stored.  It still meets the spec as an implementation in this regard  
> because the spec doesn't say what it should do for this issue.

All this is beside the points being discussed, Gregg.

>
>
>>>> Let me mention that OSGi has taken 10 years to get where it is  
>>>> and the big breakthrough was when it was adapted by Eclipse.   
>>>> JINI is no youngster either.  There are lots of technologies  
>>>> started in the late 1990s that are just coming around.
>>>
>>> OSGi had lots of problems and incomplete bits and pieces.  It was  
>>> a concept which need lots of refinement.  By the time all is said  
>>> and done, it will not be much more than a restatement of the rules  
>>> and API of Java classloaders expressed as a textual description of  
>>> what one would code.  Does that make it valuable? I'm sure many,  
>>> who don't understand what happens in the trenches, how things  
>>> relate and what things must be done, will feel fine to use OSGi,  
>>> because it will create appropriate limits and controls to cause  
>>> them to do things largely, correctly.  But, it will present limits  
>>> on the total possibilities, or it will just be re-expression of  
>>> the Java language constructs that one can program class loading  
>>> and container systems with today.
>> If you think that OSGi is merely a clever way to use class loaders,  
>> you are missing the boat, I think.  OSGi provides a lifecycle  
>> service and is a system with emergent properties far beyond a mere  
>> class loader mechanism, which is probably a tautology but a good one.
>
> If I dereference a classloader, it is unloaded, that's lifecycle  
> management.

No.  That is not true.  Did you know that OSGi is used with CLDC?

>
>
> from 2.1 in the JSR 291 proposal:
>
> This specification will define a dynamic component framework  
> including component lifecycle for existing Java SE platforms. The  
> dynamic component model will support assembly of applications from  
> components and support implementation detail hiding between  
> components as well as lifecycle management of those components.
>
> The specification will be built upon capabilities in existing Java  
> SE platforms and provide a consistent and predictable dynamic  
> component model across the family of Java platforms in conjunction  
> with JSR 232 for Java ME (CDC).
>
> The specification will enable components to be declared through  
> metadata and be assembled at runtime using a class loader delegation  
> network. The specification will also allow components to be  
> dynamically life cycle managed (install, start, stop, update,  
> uninstall).
>
> This says "existing java SE platforms" so it can't do more that what  
> Java already provides in class loading.

Like I said, you don't see how systems provide emergent properties.   
The code that is written on top of Java matters.  Java itself is not  
written in Java, you know.  This is like saying Java cannot do more  
than C.  Or, this is like saying that people cannot do more than  
molecules or an engine cannot do more than what its parts can do.  The  
design of the engine makes it possible for emergent properties to come  
out of what were just leather, steel, plastic, oil.

>
>
> This says "components to be declared through metadata" and "be  
> assembled at runtime using a class loader delegation network".  It  
> also notes dynamic life cycle management.

Notice the talk about components?  Components here are not classes,  
they are components.

>
>
> If you look at the APIs there is a world of stuff there.

Our company is an OSGi member and I am the company rep for OSGi.  So,  
I have looked at it a bit.

> So, yes, in the end it is more than a classloading mechanism with  
> lifecycle control, but why?  There is more to creating a plugable  
> frame work than running code.  You have to be able to communicate  
> within and out of the framework.  It's interesting, but  
> communications is a solved problem, so I don't look at this as a  
> "value" of OSGi.

I don't understand this.

>
>
>>>>> When there is a lot of discomfort in a change people tend to  
>>>>> push back.  Discomfort comes from more than "that's the name  
>>>>> it's had for years" in this case.
>>>> For what it is worth, this also is not my experience.  That is  
>>>> plenty reason for most to push back.
>>>> Not all of course and no one in River for sure. Also not anyone  
>>>> that lives within 100 miles of me.   ;-)
>>>> I hope you accept all this with a pinch of salt but I do  
>>>> definitely not agree with your statements about how change is  
>>>> embraced in the world.
>>>
>>> Again, I didn't say change was embraced, I said value was  
>>> embraced.  Sometimes that creates change as people gravitate in  
>>> the direction of making use of a perceived value.
>> I understood you and still understand you to say that people go  
>> with or against change depending upon how they assess the suggested  
>> change.  I am disagreeing with that.  I think most people, the vast  
>> majority of people, will fight against change simply because it is  
>> change with no assessment at all.
>
> If you choose not to decide you still have made a choice...
>
> > I am not saying this is bad.  It may be good, right,
>
>> mete, etc.  I don't know.  I do know that with the status quo most  
>> people have their part and they don't want the status quo changed  
>> because then they will have to reinvent themselves.  I would be  
>> amazed if the conversation in River went different than it has.   
>> Here is a technology with great promise that is on the edge of  
>> distinction and will have to be reinvented from a different  
>> direction if it does not succeed and it is not responding to this  
>> pressure on the whole.  This is normal.
>
> The pressure has been around for a long time.  We've talked,  
> blogged, educated, enhanced and reinvented (Rio, Chiron/Seven,  
> Bantam, Harvester and many other work simplifying tools).  What  
> hasn't happened is everyone jumping on.
>
> I, personally, believe that the problem is ignorance of the problem  
> space and how Jini facilitates solutions more than anything.

I think the problem is that the code is a jumble and needs to be  
seriously rearranged and admit that I am not sure how that should be  
done just yet.  A lot of JINI I definitely want not to have as a  
person involved with certain kinds of products.  JINI is, frankly, too  
good at discovery for many projects.

> Until people really understand, it won't matter how it's packaged.   
> There will always be people who don't like a package name, don't  
> like an API, don't understand why there's not a signature without  
> Transaction etc.  All of that requires education.
>
> Now the question, for me, is can we make changes to the "packaging"  
> and the "experience" when provides the education in a way that makes  
> people hang on and learn what they need to know?
>
> This is what Niclas and others keep proding and pressing for  
> directly and indirectly.

Packaging Java is not like packaging Christmas presents or naming  
kids.  It is serious business with serious consequences.

>
>
>> I always have liked the explanations given by Thomas Kuhn in  
>> Sources of Scientific Revolution.
>
> Far out in the uncharted backwaters of the unfashionable end of the  
> Western Spiral arm of the Galaxy, there lies a small, unregarded  
> yellow sun. Orbiting this at a distance of roughly 98 million miles  
> is an utterly insignificant little blue-green planet whose ape- 
> descended life forms are so amazingly primitive, they still think  
> digital watches are a pretty neat idea.

Enjoying talking to yuu, Gregg.

Re: A Conversation: was Split JINI

[Michael McGrady <mm...@topiatechnology.com>]

I am replying to these individually to stop this thread as Niclas has  
indicated he would like.  That seems okay to me.  If anyone would like  
to contact me individually, as many already have, you are welcome to  
do so.  Normally I do not like to take active conversations offline.   
But here it has been more or less requested by Niclas.

Mike

On Dec 24, 2008, at 8:03 AM, Calum Shaw-Mackay wrote:

> You cannot have one without the other..... business services are all
> very well and good but when a business service is looked at from the
> 30000 foot view and we all know that businesses love the word
> 'automatic' when it comes to IT, you don't get the full benefits of
> re-use (that is a cornerstone of SOA) if you think of services at the
> single process-single service level.
>
> And I don't agree about the 'expressed on paper and is never
> theoretical'.... until something is proved (ie. you;ve gone and done
> it) it will always be theoretical.

Re: A Conversation: was Split JINI

[Calum Shaw-Mackay <ca...@gmail.com>]

You cannot have one without the other..... business services are all
very well and good but when a business service is looked at from the
30000 foot view and we all know that businesses love the word
'automatic' when it comes to IT, you don't get the full benefits of
re-use (that is a cornerstone of SOA) if you think of services at the
single process-single service level.

And I don't agree about the 'expressed on paper and is never
theoretical'.... until something is proved (ie. you;ve gone and done
it) it will always be theoretical.

2008/12/24 Michael McGrady <mm...@topiatechnology.com>:
> Building analogy:
>
> View A == SOA is meant to focus on what the building owner wants (business
> defined services), including resale values and future modifications.  This
> is expressed on paper and is never theoretical.
>
> View B == SOA is mean to focus on what the architect thinks the owner should
> want (IT defined services) given the nature of architecture.  This is
> expressed in the actual building and usually or even always is highly
> theoretical.
>
> Over and out of this topic.

Re: A Conversation: was Split JINI

[Gregg Wonderly <ge...@cox.net>]

Michael McGrady wrote:
> Building analogy:
> 
> View A == SOA is meant to focus on what the building owner wants 
> (business defined services), including resale values and future 
> modifications.  This is expressed on paper and is never theoretical.
> 
> View B == SOA is mean to focus on what the architect thinks the owner 
> should want (IT defined services) given the nature of architecture.  
> This is expressed in the actual building and usually or even always is 
> highly theoretical.

My view is C.  The people at the top need to adequately use the people at the 
bottom to get done what is needed.  The people at the bottom need to be able to 
use their skills, training and experience to drive value into the whole process. 
  If A and B never meet, A might start talking about technologies that don't 
need to be used and B might produce services with features that aren't needed.

Both add value or rather, neither is valueless.

Gregg Wonderly

Re: A Conversation: was Split JINI

[Michael McGrady <mm...@topiatechnology.com>]

Building analogy:

View A == SOA is meant to focus on what the building owner wants  
(business defined services), including resale values and future  
modifications.  This is expressed on paper and is never theoretical.

View B == SOA is mean to focus on what the architect thinks the owner  
should want (IT defined services) given the nature of architecture.   
This is expressed in the actual building and usually or even always is  
highly theoretical.

Over and out of this topic.

Re: A Conversation: was Split JINI

[Michael McGrady <mm...@topiatechnology.com>]

On Dec 24, 2008, at 12:29 AM, Niclas Hedhman wrote:

> On Wed, Dec 24, 2008 at 9:46 AM, Michael McGrady
> <mm...@topiatechnology.com> wrote:
>
>> You really don't understand what SOA is, Gregg.  You are talking like
>> someone who says they don't give a damn about gravity because it is  
>> just a
>> theoretical construct.  The questions are way, way, way deeper and  
>> more
>> subtle tthan you are allowing for here.
>
> I think you guys have exhausted the subject, and I think it is time  
> to end it.
>
> To summarize the views, in an analogy of buildings.
>
> Michael's view; SOA == The architecture is an expression, sometimes
> limited to the piece of paper it is expressed on, or even only as a
> thought in the architects mind.
>
> Gregg's view; SOA == The purpose of architecture is primarily to
> construct buildings. Most architecture in expressed form is in the
> buildings themselves, not admired residing on a piece of paper.
>
>
> So, Michael; You analogy with gravity is IMHO almost opposite. You
> have a more theoretical definition, and ignores the pragmatic use of
> of those theories. So, fine... Big Deal. Let it rest, the last 3-4
> rounds on the subject has not inched the discussion in any direction,
> and none will abandon the principle of definitions.


The pragmatic use of SOA is in the business rules made by businessmen:  
the creation of the Sz in SOA.  That is what i stress.  Your focus on  
the IT structures trivializes what I am saying.  I was enjoying he  
debate but you are right that it was as advertised more of a  
conversation with gregg than something appropriate to the list.   Your  
reaction to the gravity is interesting.  Anyway, as i said, i enjoyed  
the conversation, Gregg.  hanks.

MIke

Re: A Conversation: was Split JINI

[Niclas Hedhman <ni...@hedhman.org>]

On Wed, Dec 24, 2008 at 9:46 AM, Michael McGrady
<mm...@topiatechnology.com> wrote:

> You really don't understand what SOA is, Gregg.  You are talking like
> someone who says they don't give a damn about gravity because it is just a
> theoretical construct.  The questions are way, way, way deeper and more
> subtle tthan you are allowing for here.

I think you guys have exhausted the subject, and I think it is time to end it.

To summarize the views, in an analogy of buildings.

Michael's view; SOA == The architecture is an expression, sometimes
limited to the piece of paper it is expressed on, or even only as a
thought in the architects mind.

Gregg's view; SOA == The purpose of architecture is primarily to
construct buildings. Most architecture in expressed form is in the
buildings themselves, not admired residing on a piece of paper.


So, Michael; You analogy with gravity is IMHO almost opposite. You
have a more theoretical definition, and ignores the pragmatic use of
of those theories. So, fine... Big Deal. Let it rest, the last 3-4
rounds on the subject has not inched the discussion in any direction,
and none will abandon the principle of definitions.

Cheers
Niclas

P.S. Good Men know they are Right, Great Men know they are Wrong.