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] Proposal: Reorganization of SOA-RM Draft for Better


I have an initial submission for this TC if anyone is interested.  I
have kind of stopped working on it due to time constraints but would
welcome anyone else who wants to work on it.  I have not yet contributed
it to the TC but will if there is consensus.

D

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 


-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
Sent: Thursday, December 08, 2005 9:28 AM
To: Duane Nickull
Cc: Metz Rebekah; Bashioum, Christopher D; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for
Better 

Perhaps we need an OASIS spec on concept maps ....

On Dec 7, 2005, at 10:40 PM, Duane Nickull wrote:

> I believe that the problem, with is largely due to the fact there  
> is no normative reference for how to interpret concept maps.  In  
> this case, a service is neither an action nor an object.  It is  
> imply an abstract concept.
>
>
>
> D
>
>
>
> *******************************
> Adobe Systems, Inc. - http://www.adobe.com
> Vice Chair - UN/CEFACT  http://www.uncefact.org/
> Chair - OASIS SOA Reference Model Technical Committee
> Personal Blog - http://technoracle.blogspot.com/
> *******************************
>
>
>
> From: Metz Rebekah [mailto:metz_rebekah@bah.com]
> Sent: Wednesday, December 07, 2005 7:18 PM
> To: Bashioum, Christopher D; soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> From: Bashioum, Christopher D [mailto:cbashioum@mitre.org]
> Sent: Wednesday, December 07, 2005 5:06 PM
> To: Metz Rebekah; soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> Rebekah,
>
>
>
> what about the potential of an act?
>
>
>
> [->] The potential of service is an offer.
>
>
>
> I have a problem with the following
>
>
>
> <Snip>
>
> The actual invocation and performance of the capability is the  
> service; i.e. the action.
>
> </Snip>
>
>
>
> if I understand what you are saying here, it would imply that a  
> service is not a service until it is actually performing an  
> action.  During the time that it is "waiting" to perform an action  
> it is not a service, nor is it after it has completed the action it  
> was created to do.
>
>
>
> [->] yes, you are right.  That is exactly what I'm implying.  The  
> service isn't performing the action, the implementation of the  
> action is.  The service is the performance.
>
>
>
>
>
> In Duane's diagram, the service exists independent of the  
> interaction.  However, the interaction is what causes the real- 
> world effect.
>
>
>
> I'm not sure I buy the other statement that a service is an act as  
> opposed to an object.  Isn't it an object (in that it exists) who's  
> purpose is to perform an act?
>
> [->] So I'll ask a question in return.  Let's assume the statement  
> is true.  If a service exists as an object that is independent of  
> the capability who's purpose it is to perform; what differentiates  
> the service from the capability?
>
>
>
>   For that matter, is the capability what is actually providing the  
> "action" and the service is the means to access that action?
>
> [->] From this perspective, what differentiates the service from  
> the service access point?
>
>
>
> [->] My point is that the conceptualization of service as an object  
> doesn't provide resolution to these questions.  It is for this  
> reason that I started examining service as a verb rather than a  
> noun.  From that perspective, the concepts and the relationships  
> between them clarified.
>
>
>
> Rebekah
>
>
>
> From: Metz Rebekah [mailto:metz_rebekah@bah.com]
> Sent: Wednesday, December 07, 2005 4:37 PM
> To: soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
> Gosh - if this email came through in some weird format for everyone  
> else, I am terribly sorry about the wacky formatting of this email  
> thread.  Not sure if everyone saw it as I did, but at least my  
> outlook client puked =)
>
>
>
> Uh-oh.  We seem to be starting to head back to the service as an  
> object as opposed to an act.  I still do not believe that a service  
> is an 'object.'   In fact, I believe that assumption has caused  
> much of the difficulty in figuring out what a service actually is.
>
>
>
> What is invoked is a capability, consistent with the execution  
> context and so to produce real world effects.  The actual  
> invocation and performance of the capability is the service; i.e.  
> the action.  Hence I maintain that visibility, interaction and  
> effect are the interrelated concepts often (yet confusingly)  
> referred to with a shorthand nomenclature of 'service.'
>
>
>
> As far as roles go, the very essence of the word service is the  
> recognition that <someone> does <something> for <someone else>.  I  
> would agree that any other specification of this generalization (uh...

> isn't that an ontology) belongs in something other than the RM.
>
>
>
> Rebekah
>
>
>
> Rebekah Metz
>
> Associate
>
> Booz Allen Hamilton
>
> Voice:  (703) 377-1471
>
> Fax:     (703) 902-3457
>
>
>
> From: Ken Laskey [mailto:klaskey@mitre.org]
> Sent: Wednesday, December 07, 2005 4:19 PM
> To: Metz Rebekah
> Cc: Jones, Steve G; marchadr@wellsfargo.com; tmathews@lmi.org;  
> mattm@adobe.com; soa-rm@lists.oasis-open.org;  
> frank.mccabe@us.fujitsu.com; goran.zugic@semantion.com;  
> McGregor.Wesley@tbs-sct.gc.ca; dnickull@adobe.com;  
> sallystamand@yahoo.com
> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> inline
>
>
>
> On Dec 7, 2005, at 4:00 PM, Metz Rebekah wrote:
>
>
>
> Comments inline...
>
>
>
> From: Ken Laskey [mailto:klaskey@mitre.org]
>
> Sent: Wednesday, December 07, 2005 3:43 PM
>
> To: Jones, Steve G
>
> Cc: marchadr@wellsfargo.com; tmathews@lmi.org; mattm@adobe.com; soa- 
> rm@lists.oasis-open.org; frank.mccabe@us.fujitsu.com;  
> goran.zugic@semantion.com; McGregor.Wesley@tbs-sct.gc.ca;  
> dnickull@adobe.com; sallystamand@yahoo.com
>
> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> If I invoke a service, I am a service consumer. It does not matter  
> if I invoke the service on my own initiative or am told to do it  
> (through a targeted instruction or as part of a more complex set of  
> instructions), I am still the service consumer.
>
>
>
> [->] Agreed.
>
>
>
> I could glibly say that if I "provide" a service, I'm a service  
> provider, but I fear things are not that simple. Is the entity that  
> created the service its provider, or the one who maintains it, or  
> the one who hosts it, or the one who pays for it, or ...?
>
> [->] I see this being a question of 'what are the roles' versus  
> 'who plays the roles'.   At first pass, it seems right that we  
> recognize the roles @ the RM level and leave the details of  
> determining the best way to decide how to assign some entity into  
> that role to the RA.
>
>
>
> I think it is easy to start naming roles but difficult to stop, and  
> the roles will get more use-specific.
>
>
>
> Luckily, from the RM standpoint, we don't care.
>
> [->] or do we just delegate =)
>
>
>
> ... to someone who has no choice but to care ;-)
>
> To be used within the context of SOA, the service must be visible,  
> must be able to take part in an interaction
>
> [->] Here it sounds like the service is an active player in an  
> interaction.  Isn't it that the service consumer and provider  
> interact (as specified...?
>
>
>
> Isn't the service an active player? I invoke it to get its real  
> world effect, so it certainly sounds like it does something.
>
>
>
> (as specified by the established execution context), and must  
> produce a real world effect (which I assume may in some  
> circumstances be null). It has been "provided" but we don't care  
> how or by whom.
>
>
>
> So, in summary, there's a lot of muddy water but sometimes we can  
> avoid playing in it. :-)
>
> [->] Or we can draw a circle around it and leave that to the RA =)
>
>
>
> ... at which point you initially choose RA cases that you can more  
> cleanly defined. You eventually get to the tougher ones, but we  
> should learn to ride a bicycle before we get a motorcycle (unless  
> Duane has a different perspective)
>
>
>
> Ken
>
> [->] Rebekah
>
>
>
> Ken
>
>
>
>
>
> If I make a service available for someone to invoke (and here I  
> would say that "make available"
>
> On Dec 7, 2005, at 4:47 AM, Jones, Steve G wrote:
>
>
>
>
>
> To add some mud into the water...
>
>
>
> Many Bus architectures do "enrichment" of messages between consumer  
> and producer, including the invocation of other services to perform  
> that enrichment (e.g stock quote returns current price, enrichment  
> provides the last ten days closing price).  They may also do  
> calculations that result in the non-connection or "empty" return  
> from the service (e.g. if you call for "last five minutes trades"  
> after the market has closed... its an empty set).  So while I agree  
> that the service consumer is key it's sometimes hard to identify  
> the true consumer and the true producer of a service within a  
> virtualised bus.
>
>
>
> Steve
>
>
>
>
>
>
>
> From: McGregor.Wesley@tbs-sct.gc.ca [mailto:McGregor.Wesley@tbs- 
> sct.gc.ca]
>
> Sent: 06 December 2005 19:09
>
> To: klaskey@mitre.org; marchadr@wellsfargo.com; dnickull@adobe.com;  
> goran.zugic@semantion.com; mattm@adobe.com; tmathews@lmi.org;  
> sallystamand@yahoo.com; frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> I agree with Ken.
>
>
>
> The service consumer is the key concept that indicates the entity  
> that invoked the service in the first place.
>
>
>
> A brokering service or service actor is merely a middle-man.
>
>
>
> Wes
>
> -----Original Message-----
>
> From: Ken Laskey [mailto:klaskey@mitre.org]
>
> Sent: December 6, 2005 2:02 PM
>
> To: marchadr@wellsfargo.com; dnickull@adobe.com;  
> goran.zugic@semantion.com; mattm@adobe.com; tmathews@lmi.org;  
> sallystamand@yahoo.com; frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> I could argue that a broker consumes the service on someone else's  
> behalf.  In reality, service actor seems too nondescriptive because  
> either the consumer or the provider can be thought of as an actor.
>
>
>
> Ken
>
>
>
> At 01:45 PM 12/6/2005, marchadr@wellsfargo.com wrote:
>
>
>
> I hate to stir things up a bit, but can you change the service  
> consumer term to service actor?
>
> Since in the case of brokering the service actor is not consuming  
> but brokering a request to another service.
>
> The broker service can be a service actor upon the service but  
> might not really consume any part of the service since it is a pass  
> through.
>
>
>
> But I guess this is a matter of opinion.
>
>
>
> - Dan
>
> -----Original Message-----
>
> From: Ken Laskey [ mailto:klaskey@mitre.org]
>
> Sent: Tuesday, December 06, 2005 10:39 AM
>
> To: Duane Nickull; Goran Zugic; Matt MacKenzie; MATHEWS, Tim; Sally  
> St. Amand; frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
>
>
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> I think we need to add some words to the RM to capture this  
> discussion.  We cover part of this in the beginning of Section  
> 3.2.1 but need to be more specific that:
>
>
>
> - a service consumer can be a human or a software agent;
>
>
>
> - a service consumer can invoke any number of services (including a  
> single service in isolation) and can chain the output of some  
> services to act as the input of others;
>
>
>
> - from the perspective of a given service, the occurrence of such  
> chaining would not be visible;
>
>
>
> - the service consumer can be implementing a business process;
>
>
>
> - the specific of a business process do not change the basic SOA  
> concepts as described in the RM; however, the specific architecture  
> that one designs and implements will reflect the business process  
> and make use of specific service instances that corresponds to the  
> real world effects that the business process hopes to realize.
>
>
>
> Now that said, and in full appreciation that we agreed earlier that  
> mechanisms which combine services (e.g. choreography,  
> orchestration) are out of scope, is it sufficient for words, such  
> as those suggested above, to be included somewhere within the  
> current discussion or do we need to pull it out into a subsection  
> on its own?  As an example of the former, we tried to deal with  
> loose-coupling and coarse-grained with words at the end of Section  
> 2.1.
>
>
>
> Ken
>
> At 12:23 PM 12/6/2005, Duane Nickull wrote:
>
>
>
> Goran:
>
>
>
> I slightly disagree with your assertions, probably based on  
> semantics.  For a service to "participate" in a process, it would  
> have to be aware of the process (which many will not be).  A better  
> way to depict this may be to state "services may be aggregated and  
> used by processes" and "processes may be represented/exposed as  
> services".  There are really no limits to the number of layers that  
> can be present.  Attached is a UML CVD depicting such.
>
>
>
> A key rationale of why process is not part of SOA is that services  
> cannot see process.  They are not aware of whether they are being  
> called as part of a process vs. as an individual service.  If the  
> "s" part of SOA cannot see or touch that, it cannot be part of the RM.
>
>
>
> The chicken and egg discussion you bring forward is a requirement  
> for those building services to strongly consider the business  
> process when designing their service infrastructure.  Accordingly,  
> it is not really part of the RM for SOA yet I agree that it is a  
> very important consideration.
>
>
>
> For your messages to get to the list, you must join as a  
> "applicant" rather than an "observer" as per OASIS process.
>
>
>
> Duane
>
>
>
> *******************************
>
> Adobe Systems, Inc. - http://www.adobe.com
>
> Vice Chair - UN/CEFACT  http://www.uncefact.org/
>
> Chair - OASIS SOA Reference Model Technical Committee
>
> Personal Blog - http://technoracle.blogspot.com/
>
> *******************************
>
>
>
>
>
> From: Goran Zugic [ mailto:goran.zugic@semantion.com]
>
> Sent: Monday, December 05, 2005 8:47 PM
>
> To: Duane Nickull; Matt MacKenzie; MATHEWS, Tim; Sally St. Amand;  
> frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> Duane,
>
>
>
> Thanks for the response. Yes I would like to see the PPT. I hope  
> you do not mind if I add few more thoughts related to services and  
> business processes:
>
>
>
> Services participate in a business process to add some value to it.  
> They can be governed and evaluated using business process metrics.  
> One service can participate in many business processes and provide  
> value to each of them according to the context within that process.  
> As far as SOA is concerned it is as important to know what the  
> service does, how it can be discovered, contacted, invoked,  
> executed, etc. as it is to be able to use it within the process  
> context, measure it and assess its value from the business process  
> requirements point of view. SOA needs to avoid typical new  
> technology chicken and egg syndrome, e.g. companies not producing  
> services because there are no service friendly process definitions  
> to use them and not having SOA friendly process definitions because  
> there are no services to use. Services do not have to know if they  
> will be involved in the process upfront, they will be contacted on  
> demand according to the process script that is in effect, and they  
> will be contacted, checked if available, passed the arguments,  
> collected the response and according to their procedure left alone  
> to wait for another call. The process execution engine however  
> needs to invoke the service according to both service specific  
> information and the process specific information.
>
>
>
> Having just the service specific information in a model covers only  
> one part of the picture and I think it is fine as long as that  
> model is a pure service model. However I find it difficult to  
> understand that the SOA RM TC model is a SOA reference model when  
> it does not include other concepts of SOA. Unfortunately it seems  
> that we cannot get to the point where we could agree on a minimal  
> set of supported SOA concepts by a model to be the SOA RM.  We do  
> not have to and I do not want to argue with you or anybody else in  
> SOA RM TC. I am just trying to see how our works can fit together  
> in a most efficient way. We obviously need more time to better  
> understand each others thoughts and ideas and I strongly believe  
> that a constructive respectable discussion is helpful for everybody.
>
>
>
> By the way, do you know what I am supposed to do to get my messages  
> to the SOA RM list. In spite of that I am the SOA RM TC observer I  
> get a faliure notice whenever I send a note to the SOA RM.
>
>
>
> Goran
>
>
>
> ----- Original Message -----
>
> From: Duane Nickull
>
> To: Matt MacKenzie ; goran.zugic@semantion.com ; MATHEWS, Tim ;  
> Sally St. Amand ; frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
> Sent: Monday, December 05, 2005 5:02 PM
>
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> Goran:
>
>
>
> The service layer enables the process layer over top of it, however  
> during runtime, services do not know if they are part of a process  
> or being called individually (it would generally be a bad idea to  
> try to maintain the overall state of a process within each service,  
> although it could be done).  For maximum repurposing of services,  
> it would be better to have the service as a simple slave to the  
> processes that may use it.
>
>
>
> Accordingly, we made a decision that BPM, Orchestration,  
> choreography is not a core part of the RM for SOA.  We generally  
> seem to agree that many SOA implementations will include a layer of  
> BPM over top.  We are only addressing the SOA model, not the model  
> for the underlying or overarching layers.
>
>
>
> I have a PPT that explains this in more detail if you are interested.
>
>
>
>
>
> Duane
>
>
>
> *******************************
>
> Adobe Systems, Inc. - http://www.adobe.com
>
> Vice Chair - UN/CEFACT  http://www.uncefact.org/
>
> Chair - OASIS SOA Reference Model Technical Committee
>
> Personal Blog - http://technoracle.blogspot.com/
>
> *******************************
>
>
>
> From: Matt MacKenzie [ mailto:mattm@adobe.com]
>
> Sent: Monday, December 05, 2005 12:51 PM
>
> To: goran.zugic@semantion.com; MATHEWS, Tim; Sally St. Amand;  
> frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> Process orientation is only one of multiple potential integration  
> with service oriented architecture.  SOA-RM is laying the  
> foundation for durable architecture based on the core concept of  
> service orientation.  We recognize that process oriented  
> architecture is a natural fit with service orientation...but so are  
> things like event orientation.
>
>
>
>
>
> -matt
>
>
>
> From: goran.zugic@semantion.com [ mailto:goran.zugic@semantion.com]
>
> Sent: Monday, December 05, 2005 3:36 PM
>
> To: MATHEWS, Tim; Matt MacKenzie; Sally St. Amand;  
> frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better
>
>
>
> I think that SOA RM has done good job documenting well-known  
> service related concepts and defining some new ones.
>
>
>
> I do not see other details besides service and service-related  
> concept definitions in the current SOA RM committee draft right  
> now. I look forward to seeing the completion of the model you are  
> working on with the bottom-up approach.
>
> Business, business processes and collaboration aspects of business  
> are important to address in the model what is not the case with the  
> current content of the SOA RM committee draft. By a business  
> process I mean a generic business process entity which has common  
> components (activities, decisions, etc) and relationships between  
> them that can be used to model a business process in any  
> environment regardless of what business we support and technology  
> we use. I agree with Sally that a link between business processes  
> and services should be one of key requirements any SOA reference  
> model should try to meet.
>
>
>
> I am not sure what SOA with services brings to business when the  
> link between the business processes and services and overall  
> business process semantics in the SOA context are not considered to  
> be important aspects in a SOA-based reference model.
>
>
>
> Goran
>
> -----Original Message-----
>
> From: MATHEWS, Tim [ mailto:tmathews@lmi.org]
>
> Sent: Monday, December 5, 2005 12:34 PM
>
> To: 'Matt MacKenzie', 'Sally St. Amand', frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better "Componentization"
>
> Matt - I am not sure what point you are trying to make by this?  I  
> agree with your premise of a bottom up effort, as this was one of  
> the operating assumptions that was made from the beginning.
>
>
>
> But, I am confident it is the business environment that is  
> independent from the reference model.
>
>
>
> TM
>
>
>
> From: Matt MacKenzie [ mailto:mattm@adobe.com]
>
> Sent: Monday, December 05, 2005 11:58 AM
>
> To: Sally St. Amand; frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better "Componentization"
>
> Sally,
>
>
>
> A reference model actually needs to be a bottom up effort.  We  
> leave the ever so popular ?top-down? approach to folks like ebSOA J
>
>
>
> We?re creating a vocabulary and general understanding of what I  
> hope we can call a discipline of computer science in the future.   
> This means, we need a durable reference model that is not dependent  
> on the current business environment.
>
>
>
> -matt
>
>
>
> From: Sally St. Amand [ mailto:sallystamand@yahoo.com]
>
> Sent: Monday, December 05, 2005 10:19 AM
>
> To: frank.mccabe@us.fujitsu.com
>
> Cc: soa-rm@lists.oasis-open.org
>
> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for  
> Better "Componentization"
>
>
>
> Frank
>
>
>
> This is in response to your request on last week?s conference call,  
> if anyone has comments speak now. I also think that the recent  
> comments on clarifying sections are a reflection of my issues with  
> the specification.
>
>
>
> I agree with the majority of points made/described in ver 10. My  
> issues are with what is not in this draft. Based on Fig 1 the Refe!  
> rence Model is guided by Reference Architectures, Concrete  
> Architectures, Profile & Related Models. They in turn account for  
> requirements, motivation & goals. This is creating a Reference  
> Model from the bottom up. I believe a Reference Model should  
> reflect a top down approach.
>
>
>
>
>
> The Reference Model needs to reflect the environment, the strategy  
> and the priorities of the business/mission/collaboration.  This  
> will impact the construction of services. A service is a business  
> task or activity that is realized through technology. The draft  
> does a good job of describing how that realization happens. But it  
> doesn?t provide a sufficient link between processes and services.  
> The draft makes the point that the central focus of! SOA is the  
> task of business function?getting something done. A business  
> process is made up of tasks and activities to achieve a goal  
> (getting something done). The concept of creating the service from  
> the tasks and activities in a process is important. For example,  
> where on the continuum of fine grained to coarse grained should a  
> particular service be; this will affect interaction, reusability.  
> The relationship between processes and services needs to be in the  
> Reference Model.
>
>
>
> While I saw that there is a note saying the glossary is still in  
> flux, since one of the objective of the Reference Model is a  
> vocabulary, having less in the glossary might be a better option.  
> Is semantic integration a guiding principle of SOA?
>
>
>
> With respect to conformance there needs to be business results.  
> That is an SOA should provide demonstrable mission accomplishments,  
> e.g. ROI, match a competitors distribution channel. SOA is not a  
> technology. Conformance should provide operational accomplishments,  
> these should be measurable.
>
>
>
> Sally
>
>
>
>
>
> !
>
>
>
>
>
>



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