OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm][issue:structure] draft 07, sect 2, line 201, Figure 2-1


> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Wednesday, May 25, 2005 1:39 PM
> To: McGregor.Wesley@tbs-sct.gc.ca; soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm][issue:structure] draft 07, sect 2, line 
> 201, Figure 2-1
> 
> Not to cause too much more roiling, but it just occurred to 
> me that, as a potential consumer who does not find a specific 
> service ready to be consumed, might we not also want to allow 
> consumers a mechanism in our RM by which they can advertise 
> for a service? If so, what do we call that? 

eBay. ;)

In all honesty, I was actually half-serious - I foresee the day where
large-scale "services markets" will come into existence. In fact, if you
add a "Priceline" aspect to it, a service consumer can search for a
service whose price (perhaps per transaction) meets its requirement. But
we're very far from that.

The rest is another thread, on another list.

In summary, I think the notion you mention is far-future - too far to be
mentioned in our spec.

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 
> Where in the 
> model does it belong? It is much like a service request for 
> which there is not at a given point in time, an available service.
> 
> Hmmmnnn?
> Rex
> 
> At 10:13 AM -0400 5/25/05, <McGregor.Wesley@tbs-sct.gc.ca> wrote:
> >I am in agreement with this.
> >
> >This implies then that there is no real dependency on Service from 
> >Service Description other than to allow a possible link to 
> the service 
> >(a placeholder if you will)
> >
> >
> >  -----Original Message-----
> >From:	Christopher Bashioum [mailto:cbashioum@mitre.org]
> >Sent:	May 25, 2005 9:05 AM
> >To:	soa-rm@lists.oasis-open.org
> >Subject:	RE: [soa-rm] David Linthicum Says: "ESB versus 
> Fabric.Stop It!"
> >
> >  I would think that one would want to be able to describe a service 
> >independent of whether or not it is consumable at a given 
> point in time 
> >to enable the concurrent development of services.  In which case you 
> >would want the service description to indicate whether or not the 
> >service was available for consumption (and if not, then 
> maybe the target date for availability).
> >
> >-----Original Message-----
> >From: McGregor.Wesley@tbs-sct.gc.ca 
> >[mailto:McGregor.Wesley@tbs-sct.gc.ca]
> >Sent: Tuesday, May 24, 2005 3:14 PM
> >Cc: soa-rm@lists.oasis-open.org
> >Subject: RE: [soa-rm] David Linthicum Says: "ESB versus 
> Fabric.Stop It!"
> >
> >Duane,
> >
> >I agree with you. There is no point describing a service if 
> a link to 
> >its endpoint cannot be found.
> >
> >Does this then imply that we have a "must-have" relationship 
> which is 
> >far stricter than just a dependency?
> >
> >Finally, why describe a service if it cannot be consumed, for future 
> >reservations maybe similar to XML namespaces?
> >
> >Comments anyone...
> >
> >Wes
> >  -----Original Message-----
> >From:	Duane Nickull [mailto:dnickull@adobe.com]
> >Sent:	May 24, 2005 2:56 PM
> >To:	Michael Stiefel
> >Cc:	soa-rm@lists.oasis-open.org
> >Subject:	Re: [soa-rm] David Linthicum Says: "ESB versus 
> Fabric.Stop
> >It!"
> >
> >Endpoints are part of a service description IMO.  Orchestration of 
> >multiple services is out of the scope of  the core RM, much the same 
> >way as how multiple houses are positioned next to each other 
> in a grid 
> >layout is un-necessary in order to define a RM for house.
> >
> >A service or house do not have to exist amongst multiple houses in 
> >order to be services/houses.
> >
> >Duane
> >
> >Michael Stiefel wrote:
> >
> >>  Could we then conceive of endpoints and orchestration in such a  
> >> fashion? Or is the critical point aspect or attribute in 
> which case  
> >> endpoint qualifies, but orchestration does not.
> >>
> >>  To make a grammatical analogy, the RM defines a substantive, and  
> >> therefore adjectives (aspects and attributes) are part of 
> the RM, but  
> >> verbs (actions) are not.
> >>
> >>  (side note: I know verbs have aspect, but we are not 
> using the term  
> >> that way).
> >>
> >>  Michael
> >>
> >>  At 02:34 PM 5/24/2005, Duane Nickull wrote:
> >>
> >>>  Since Structural Integrity is an aspect of all houses, 
> it could be  
> >>> part of a RM as an abstract concept.  Even if you do not 
> explicitly  
> >>> design a house to have a certain set of structural integrity  
> >>> parameters, it still does.  It is not a component itself, 
> just an  
> >>> aspect or attribute.
> >>>
> >>>  Duane
> >>>
> >>>
> >>>  Michael Stiefel wrote:
> >>>
> >>>>  I thought of structural integrity in terms of the entire house, 
> >>>> not  just a wall, but I think your point remains the same.
> >>>>
> >>>>  Granted that each architecture needs to specify its structural  
> >>>> integrity, but shouldn't the RM have the concept of structural  
> >>>> integrity since it is an abstract concept shared by all RAs.
> >>>>
> >>>>  Michael
> >>>>
> >>>>  At 02:06 PM 5/24/2005, Duane Nickull wrote:
> >>>>
> >>>>>  The RM does not necessarily have to get into cardinality rules 
> >>>>> IMO,
> >  >>>> unless they are very obvious.  In the case of a 
> house, you may 
> > not  >>>> make consistent rules stating that every house 
> has to have 
> > at least
> >>>>>  three walls since a wall can be curved or any number of walls 
> >>>>> from
> >>>>>  3 up.  You may be able to infer from the relationships 
> that there  
> >>>>> is a certain cardinality if the RM for a house said 
> that each room  
> >>>>> has one door.
> >>>>>  That would declare an association between the number 
> of rooms to  
> >>>>> the number of doors.
> >>>>>
> >>>>>  Structural integrity is an aspect of a wall, which must be  
> >>>>> specialized for each architecture based on a number 
> criteria.  The  
> >>>>> RM declares what the wall is and its' purpose, the 
> architect has  
> >>>>> the job of specifying the actual walls to be used for each  
> >>>>> architecture and ensuring they map back to requirements.
> >>>>>
> >>>>>  You are right - analogies are not definitions, however I have 
> >>>>> found  them very useful in conveying the meaning.
> >>>>>
> >>>>>  Duane
> >>>>>
> >>>>>  Michael Stiefel wrote:
> >>>>>
> >>>>>>  Does the RM understand that some of the concepts are 
> unique and  
> >>>>>> some multiple (without an exact number, you could have one  
> >>>>>> circular wall, 3 walls, 4 walls, etc.)?
> >>>>>>
> >>>>>>  Using your analogy, how does the RM deal with 
> concepts such as  
> >>>>>> structural integrity. Structural integrity would apply to all  
> >>>>>> house RAs. In my way of thinking concepts such as 
> endpoints or  
> >>>>>> orchestration are analogous to this.
> >>>>>>
> >>>>>>  In the analogy I would see the reference architecture as 
> >>>>>> Colonial  American Reference Architecture, or even more 
> >>>>>> specifically  Colonial American Cape Ann, or Colonial American 
> >>>>>> Greek Revival  reference architectures.
> >>>>>>
> >>>>>>  Analogies are useful, but they are not definitions.
> >>>>>>
> >>>>>>  Michael
> >>>>>>
> >>>>>>  At 12:56 PM 5/24/2005, Duane Nickull wrote:
> >>>>>>
> >>>>>>>  RA means Reference Architecture.  As per the 
> previous emails on  
> >>>>>>> this subject, it is a generalized architecture.
> >>>>>>>
> >>>>>>>  The relationship is that architects use a RM as a 
> guiding model  
> >>>>>>> when building a RA.
> >>>>>>>
> >>>>>>>  For example, if you are architecting a house, an RM 
> may explain  
> >>>>>>> the concepts of gravity, a 3D environment, walls, 
> foundations,  
> >>>>>>> floors, roofs, ceilings etc.  It is abstract however. 
>  There is  
> >>>>>>> nothing specific like a wall with measurements such 
> as 8 feet  
> >>>>>>> high.  Note that the RM has only one each of these 
> things - it  
> >>>>>>> does not have 4, 16, 23 walls, just one as a concept.
> >>>>>>>  The architect may uses this model to create a specific  
> >>>>>>> architecture for a specific house (accounting for 
> such things as  
> >>>>>>> property, incline, climate etc) or an architect MAY 
> elect to use  
> >>>>>>> it to build a more generalized reference architecture.  The  
> >>>>>>> latter is often done by architects who design houses. 
>  When they  
> >>>>>>> sell a house, they must often re-architect the RA for 
> specific  
> >>>>>>> implementation details such as incline of land, 
> climate, facing  
> >>>>>>> the sun etc..
> >>>>>>>
> >>>>>>>  So why do we need a RM?  Simple - we now have 
> logical divisions  
> >>>>>>> amongst the components of a house and what they mean. 
>  That way,  
> >>>>>>> when a company says " we are a flooring company..", that is  
> >>>>>>> meaningful since we all know what that means.  The 
> same applies  
> >>>>>>> to a roofing company.  Without the basic consensus on the 
> >>>>>>> logical  divisions, a roofing contractor may also try 
> to include 
> >>>>>>> the  ceiling and walls as part of his offerings.
> >>>>>>>  That would not work and not allow the general contractor to 
> >>>>>>> build  a house very easily since there may not be 
> consensus upon 
> >>>>>>> the  division of labor and components to build the house.
> >>>>>>>
> >>>>>>>  Do you guys think an explanation of this nature may 
> be good to  
> >>>>>>> include in the introduction section?
> >>>>>>>
> >>>>>>>  Duane
> >>>>>>>
> >>>>>>>  Chiusano Joseph wrote:
> >>>>>>>
> >>>>>>>>  What is an RA? What is the relationship between an 
> RM and an RA?
> >>>>>>>>  What is
> >>>>>>>>  the RM->RA path for SOA?
> >>>>>>>>
> >>>>>>>>  Matt also submitted last week (I believe) that we 
> may not even  
> >>>>>>>> need an
> >  >>>>>>> RA. How should that change our notion of RM, if at all?
> >>>>>>>>
> >>>>>>>>  Joe
> >>>>>>>>
> >>>>>>>>  Joseph Chiusano
> >  >>>>>>> Booz Allen Hamilton
> >>>>>>>>  Visit us online@ http://www.boozallen.com
> >>>>>>>>
> >>>>
> >>
> >>
> 
> 
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]