[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] [Duane,need clarification] RE: [soa-rm]Amazon.comandHurricane Catrina - ServiceContext? Service "Veneer"?
I apologize if you interpreted my tone negatively. Why bother with SOA if you don't plan to enforce some basic rules of reusability? In the government context, I would expect that reusability would be important as a way of reconfiguring business processes in a non destructive way. In fact, as a Canadian citzen...I'd hope that it is important :-) If a service is not composable without context, perhaps the service needs to be split up. *shrug*, YMMV. -matt McGregor.Wesley@tbs-sct.gc.ca wrote: >Matt, > >I take exception to your tone. > >Each concept in the reference model must clearly define its boundaries. Failure to do so will only have the work ignored due to lack of clarity. > >You must remember that not all services are reusable nor should they be. Just having a sound service description available somewhere is enough in a lot of cases for initial take-up and System of Record. > >We all strive for reusability, but in the majority of cases it is very hard to create given the nature of the business (especially in a government context). > >Wes > > > -----Original Message----- >From: Matthew MacKenzie [mailto:mattm@adobe.com] >Sent: September 8, 2005 11:06 AM >To: McGregor, Wesley >Cc: dnickull@adobe.com; chiusano_joseph@bah.com; soa-rm@lists.oasis-open.org >Subject: Re: [soa-rm] [Duane,need clarification] RE: [soa-rm] Amazon.comandHurricane Catrina - ServiceContext? Service "Veneer"? > >First off, the RM should not care what you decide to feed into your >services. Even though it is bad form to require services to understand >operations outside of its scope (think reusability), it is not our place >as RM authors to discourage bad architecture. > >Secondly, the whole idea of composite services and orchestration is out >of scope. People, we have to get beyond this fixation with particular >architectures, it is getting tiresome and is not helping us get to our >goal of publishing an RM. And I'll throw in a note about orchestration: >IT IS THE ORCHESTRATOR'S JOB TO MANAGE STATE! This can be done without >passing that state between each step of the orchestration. Think about >the inherent orchestration involved in shipping a container from >Singapore to Boise, Idaho. Does the crane operator in Singapore who is >dropping the container onto a ship care that the box is destined for >Idaho? Hell no. He is told: ContainerA -> Ship1. When the ship hits >San Fran or wherever, the container number is delivered to its owner, >who then figures out where it has to go. It is important that in a >disconnected, service oriented world that state be avoided wherever >possible so that services can be reused and included in diverse >orchestrations. NONE of this really matters to the RM, only the RAs. > >-matt > >McGregor.Wesley@tbs-sct.gc.ca wrote: > > > >>Respectfully I disagree. >> >>You are stating that a service MUST NOT have any input that is state oriented. I believe that notion is too strict and hence the usage of the term SHOULD is more appropriate. >> >>By saying MUST NOT implies that any derived architecture and their services can NEVER have a state as input which would render a lot of collaboration services impossible. Intra-enterprise services which can greatly benefit from state-based input could never exist then. >> >>I would allow for MUST NOT (greater restriction) on an RA but SHOULD (open ended) on an RM. >> >>Wes >> >> >>-----Original Message----- >>From: Duane Nickull [mailto:dnickull@adobe.com] >>Sent: September 7, 2005 5:15 PM >>To: McGregor, Wesley >>Cc: chiusano_joseph@bah.com; soa-rm@lists.oasis-open.org >>Subject: Re: [soa-rm] [Duane, need clarification] RE: [soa-rm] Amazon.comandHurricane Catrina - Service Context? Service "Veneer"? >> >>Wes: >> >>There is a differentiator. A service may be designed and configured to >>support an orchestration. It may even be split into two services to >>support commit and rollback functionality. However, at the time it gets >>called, it has no notion (state) what lies beyond its' event horizon >>(its' interface/service/action boundary etc). >> >>Duane >> >> >>McGregor.Wesley@tbs-sct.gc.ca wrote: >> >> >> >> >> >>>I would argue that the Service Description allows for the possibility that this information can be made requisite. >>> >>>The Service Description is vague enough at this point not to preclude it. Thus the word SHOULD is appropriate. >>> >>>-----Original Message----- >>>From: Duane Nickull [mailto:dnickull@adobe.com] >>>Sent: September 6, 2005 6:08 PM >>>To: Chiusano Joseph >>>Cc: soa-rm@lists.oasis-open.org >>>Subject: Re: [soa-rm] [Duane, need clarification] RE: [soa-rm] Amazon.com andHurricane Catrina - Service Context? Service "Veneer"? >>> >>>Joseph et al: >>> >>>This is partially true. Orchestration of multiple services is not >>>something that will be a normative component of the RM, however it may >>>be mentioned for illustration purposes. See Vancouver meeting notes for >>>more details. >>> >>>There are many reasons for this. Services themselves would not be aware >>>of whether they are being called as part of a larger orchestration vs. a >>>single request, nor should they. There is no fundamental difference in >>>the way a service may be called that distinguish these two things. >>> >>>I am very tied up right now but we can table this for our next call >>>(Agenda pending). >>> >>>Duane >>> >>>Chiusano Joseph wrote: >>> >>> >>> >>> >>> >>> >>> >>>>Okey-dokey. I request clarification from the Chair at this point for >>>>us all, please, on where orchestration fits in/will fit in with our RM >>>>once our 12-month (per our charter) product is released. >>>>Joe >>>>Joseph Chiusano >>>>Booz Allen Hamilton >>>>O: 703-902-6923 >>>>C: 202-251-0731 >>>>Visit us online@ http://www.boozallen.com <http://www.boozallen.com/> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* John Harby [mailto:jharby@gmail.com] >>>> *Sent:* Tuesday, September 06, 2005 1:14 PM >>>> *To:* soa-rm@lists.oasis-open.org >>>> *Subject:* Re: [soa-rm] Amazon.com and Hurricane Catrina - Service >>>> Context? Service "Veneer"? >>>> >>>> I may have missed something several months ago but I would call >>>> that approach questionable at best. >>>> >>>> On 9/6/05, *Chiusano Joseph* < chiusano_joseph@bah.com >>>> <mailto:chiusano_joseph@bah.com>> wrote: >>>> >>>> John, >>>> I believe this was determined several months ago (I say that >>>> in a helpful way, not in a criticizing way). I don't believe >>>> we are limited at all in our capability to define service. >>>> It's just that we need to define certain "basic" aspects >>>> first, and have other TCs (or perhaps this one in a later >>>> phase) extend our RM to include capabilities such as >>>> orchestration. We've sometimes referred to this as a POA >>>> (Process-Oriented Architecture). >>>> Hang in there, we'll get there..... >>>> Joe >>>> Joseph Chiusano >>>> Booz Allen Hamilton >>>> O: 703-902-6923 >>>> C: 202-251-0731 >>>> Visit us online@ http://www.boozallen.com >>>> <http://www.boozallen.com/> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* John Harby [mailto:jharby@gmail.com >>>> <mailto:jharby@gmail.com>] >>>> *Sent:* Tuesday, September 06, 2005 12:44 PM >>>> >>>> *To:* soa-rm@lists.oasis-open.org >>>> <mailto:soa-rm@lists.oasis-open.org> >>>> *Subject:* Re: [soa-rm] Amazon.com <http://Amazon.com> and >>>> Hurricane Catrina - Service Context? Service "Veneer"? >>>> >>>> I'm surprised that orchestration is out of scope. I could >>>> understand how specifics such as BPEL >>>> would be out of scope but many people will call things >>>> services that are lorchestrations of other >>>> services. If orchestration is out of scope then are we >>>> limited in our capability to define "service"? >>>> >>>> On 9/6/05, *Chiusano Joseph* < chiusano_joseph@bah.com >>>> <mailto:chiusano_joseph@bah.com>> wrote: >>>> >>>> Emphasizing that orchestration is out of scope for our >>>> RM (it's for another RM that can be built on top of >>>> ours), and speaking only of Web Services: I would say >>>> that all Web Services are orchestrable, but not all >>>> Web Services are "orchestration-ready". That is, in >>>> order to be "orchestration-ready" a Web Service may >>>> need to have the ability to participate in a certain >>>> protocol (e.g. the OASIS WS-CAF coordination protocol, >>>> which can be part of orchestration) by implementing >>>> that protocol. >>>> For example, a Web Service may need to have the >>>> capability to register itself with a coordinator service. >>>> Joe >>>> Joseph Chiusano >>>> Booz Allen Hamilton >>>> O: 703-902-6923 >>>> C: 202-251-0731 >>>> Visit us online@ http://www.boozallen.com >>>> <http://www.boozallen.com/> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* John Harby [mailto:jharby@gmail.com >>>> <mailto:jharby@gmail.com>] >>>> *Sent:* Tuesday, September 06, 2005 12:03 PM >>>> *To:* soa-rm@lists.oasis-open.org >>>> <mailto:soa-rm@lists.oasis-open.org> >>>> >>>> *Subject:* Re: [soa-rm] Amazon.com >>>> <http://Amazon.com> and Hurricane Catrina - >>>> Service Context? Service "Veneer"? >>>> >>>> One question I had was can all services be >>>> orchestrated or are there "orchestratable >>>> services" and "non-orchestratable services". If >>>> there is a distinction, would this orchestration >>>> capability be mitigated via policy? >>>> >>>> John Harby >>>> >>>> On 9/6/05, *Ken Laskey* <klaskey@mitre.org >>>> <mailto:klaskey@mitre.org>> wrote: >>>> >>>> The actual collection (orchestration?) of >>>> services (or more basically, capabilities that >>>> the services access?) will reflect the >>>> particular business process, but at a >>>> reference model level we can't build a >>>> different model for each business process. The >>>> challenge is to identify the concepts from >>>> which you can support any business process. >>>> (Question: have the previous drafts of SOA-RM >>>> missed any of these concepts?) A previous >>>> difficulty when looking at typical use cases >>>> is that not every SOA challenge will have a >>>> purchase order and a credit card number. While >>>> purchasing is an important use case, a SOA >>>> tailored to support the variations of >>>> purchasing may fail badly in addressing, say, >>>> the need to find and access real time disaster >>>> data. >>>> >>>> Ken >>>> >>>> At 11:23 AM 9/6/2005, marchadr@wellsfargo.com >>>> <mailto:marchadr@wellsfargo.com> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> I tend to agree with Steve's point about >>>>> having the model reflect the business >>>>> processes and then deriving the service >>>>> definition from the type of processes the >>>>> service will aggregate or use. In theory, the >>>>> payment of a product, service or donation is >>>>> not that different since at the end of the >>>>> day it becomes a transaction of a total >>>>> amount from one account to the other >>>>> (Amazon's in this case) and the entities >>>>> (product, service, or donation) are a means >>>>> to an end. >>>>> >>>>> The separation of the order versus the >>>>> purchasing would probably be the best >>>>> approach for the interface design, since the >>>>> order could vary and have polymorphistic >>>>> behavior depending on the type of entities >>>>> that are a part of the order. (In some cases, >>>>> the order would have a possibility of having >>>>> a donation and a product in the same order >>>>> from the UI point of view.) The order would >>>>> be used to hold products and start the back >>>>> office processing, while the purchase would >>>>> make the transaction of money based on a >>>>> total amount of the order. >>>>> >>>>> This brings up an issue in some ways of >>>>> whether or not the order triggers the >>>>> purchase which would result in a service >>>>> invoking another service. >>>>> The other issue I have been finding is a >>>>> return is similar to a purchase since it is >>>>> the reverse of the transaction (one account >>>>> to another with an amount), since usually it >>>>> is to late to reverse it before it actual >>>>> makes a charge. Also in the case of >>>>> purchasing large amounts of products and >>>>> paying for them and in some back office >>>>> process one product is determined to be >>>>> discontinued then the reversal of a >>>>> transaction will really be based on the >>>>> amount of that discontinued transaction and >>>>> not the total amount which would almost be >>>>> like purchasing the product back from the >>>>> customer. >>>>> >>>>> Something to think about. The context seems >>>>> to be a good approach for the ordering and >>>>> purchasing scenario. >>>>> >>>>> Dan >>>>> >>>>> -----Original Message----- >>>>> From: Jones, Steve G [ >>>>> mailto:steve.g.jones@capgemini.com] >>>>> Sent: Monday, September 05, 2005 7:30 AM >>>>> To: Ken Laskey; SOA-RM >>>>> Subject: RE: [soa-rm] Amazon.com >>>>> <http://Amazon.com> and Hurricane Catrina >>>>> - Service Context? Service "Veneer"? >>>>> >>>>> I've found that the only way to model >>>>> this is to ensure that you have a >>>>> hierarchy of service that models the full >>>>> business rather than concentrating on the >>>>> technical delivery elements. So you must >>>>> model (but not have to directly >>>>> implement) the two types of services, >>>>> which then act as containers for the >>>>> technical services. The higher order >>>>> service then has different business >>>>> processes that give different results, >>>>> but these are hidden from the service >>>>> consumers. >>>>> >>>>> What has been the biggest problem for me >>>>> has been how to represent the change in >>>>> contract (but not interface) of a service >>>>> due to its different domain. This isn't a >>>>> huge technical challenge at the moment >>>>> (as we can't define contracts at all!) >>>>> but could become a much bigger challenge >>>>> is future. Some concept of contract >>>>> inheritance might work here... >>>>> >>>>> I'm wary of describing groups as things >>>>> (like a payment service) as a capability >>>>> rather than a service as it gets tricky >>>>> on granularity, unless you mean that a >>>>> capability is a single invocation on a >>>>> service? >>>>> >>>>> If we deal in RM around Service >>>>> boundaries and the concept of hierarchy >>>>> then we don't have a new service just a >>>>> different context. Where it gets tricky >>>>> for me is when you have a service that IS >>>>> clearly re-used but is actually >>>>> completely separate. You get this in some >>>>> compliance sensitive areas where they use >>>>> identical solutions but completely >>>>> separate instances. This is different to >>>>> ones where they do that just because they >>>>> can, there is a broader context that >>>>> means they MUST be kept separate... a real >>>>> bugger to model. >>>>> >>>>> In part I'm interested in how we are >>>>> putting hierarchy into the RM? >>>>> >>>>> Steve >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> From: Ken Laskey [ mailto:klaskey@mitre.org] >>>>> Sent: 05 September 2005 15:12 >>>>> To: SOA-RM >>>>> Subject: Re: [soa-rm] Amazon.com >>>>> <http://Amazon.com> and Hurricane Catrina >>>>> - Service Context? Service "Veneer"? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Steve, >>>> >>>> I believe we are saying the same thing. If the >>>> service is specifying the item to be purchased >>>> by UPC, it is the same service in a different >>>> context. In this case, the donation would be >>>> added to the general catalog and the user >>>> interaction would be the same. I'd consider >>>> the "broader service" to be what I call the >>>> underlying capability, i.e. the money >>>> collection in return for something. The >>>> consumer sees the real world effect of that >>>> capability existing and there being a service >>>> to access it, but never sees the capability >>>> itself. >>>> >>>> However, note that with both Amazon and Apple >>>> there are new means to invoke the service >>>> (special links) and the service interacts with >>>> the consumer in ways different than the usual. >>>> For these reasons I'd say that for the new >>>> context Amazon and Apple created new services >>>> (where here I mean services in the SOA >>>> context) to repurpose existing capability (the >>>> provisioning of which may be called a service >>>> in the more general business context). I'm not >>>> sure what Amazon and Apple did made use of any >>>> SOA magic but it was nice reuse of capability. >>>> >>>> Does this bugger things up? I think it does >>>> only if we need to be definitive when you >>>> cross the line from reusing a service to >>>> having a new one. I'm not sure for the SOA-RM >>>> that we need to draw that line or even >>>> acknowledge that it may exist. >>>> >>>> Ken >>>> >>>> >>>> On Sep 5, 2005, at 4:37 AM, Jones, Steve G wrote: >>>> >>>> >>>> Again not to raise old threads... but >>>> >>>> This for me is the concept of context, the >>>> context has changed which means the impact of >>>> the service is different, its implementation >>>> and execution may however remain identical. So >>>> the "Collection" service in this case always >>>> results in Money being taken and added to a >>>> general leger with a UPC for the product code >>>> (for example). The difference is that in the >>>> charity domain it results in the further >>>> sending of that money onto the charity >>>> represented by the UPC, whereas in the >>>> purchasing domain you get a song to download. >>>> The actual collection service therefore >>>> remains unchanged but there is a broader >>>> service (whose interface you don't directly >>>> see but assume) which controls the whole process. >>>> >>>> And I can safely say that these things can be >>>> a bugger to model. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> From: Ken Laskey [mailto:klaskey@mitre.org] >>>> Sent: 05 September 2005 01:29 >>>> To: SOA-RM >>>> Subject: Re: [soa-rm] Amazon.com >>>> <http://Amazon.com> and Hurricane Catrina - >>>> Service Context? Service "Veneer"? >>>> >>>> And the answer, as always, is it depends. In >>>> my example of buying by UPC symbol, it is the >>>> same but possibly because the use of the UPC >>>> symbol has been expanded. In the case of >>>> having a new service that, let's say, >>>> automatically substitutes the charity item >>>> number for your choice of a song item number >>>> and maybe gives specialized feedback to the >>>> consumer saying thank you for responding to >>>> the hurricane emergency, I'd say it is a >>>> different service. It is derived from the >>>> original but I'd say it is different. >>>> >>>> Ken >>>> >>>> P.S. and with this busy hurricane season, we >>>> are up to Katrina. >>>> >>>> P.P.S. Another interesting aspect is if you >>>> had a computer that hadn't already accepted >>>> the iTunes terms and conditions, you were >>>> first presented with their click-through >>>> agreement before you contribute. So we also >>>> have an interesting reuse of policy and the >>>> need to form a contract. >>>> >>>> >>>> On Sep 4, 2005, at 7:14 PM, Chiusano Joseph wrote: >>>> >>>> <Quote> >>>> Is there also a concept of a service having >>>> the same interface but by operating in a >>>> different domain (e.g. charity) it acts >>>> different for the same interface? >>>> </Quote> >>>> >>>> Which raises another question we've been >>>> through before in the TC (several months ago): >>>> Is it the same service in both cases? That is, >>>> are the "normal" Amazon.com >>>> <http://Amazon.com> order placement service >>>> (with credit card info on file, and selectable >>>> each time) and this new "hurricane donation" >>>> service really the same service? >>>> >>>> Joe >>>> >>>> P.S. Not trying to resurrect a permathread - >>>> just tying a recent observation in with a past >>>> exchange, to see it in a new light. >>>> >>>> ------------------------------------------------------------------------ >>>> From: Jones, Steve G [ >>>> mailto:steve.g.jones@capgemini.com] >>>> Sent: Sun 9/4/2005 5:25 PM >>>> To: Ken Laskey; Chiusano Joseph >>>> Cc: SOA-RM >>>> Subject: RE: [soa-rm] Amazon.com >>>> <http://Amazon.com> and Hurricane Catrina - >>>> Service Context? Service "Veneer"? >>>> Is there also a concept of a service having >>>> the same interface but by operating in a >>>> different domain (e.g. charity) it acts >>>> different for the same interface? In effect >>>> its business contract is changed by a business >>>> driver outside of its scope, while its >>>> functionality (collecting money) remains the >>>> same its imperative is changed by the wider >>>> business context in which it now sits. >>>> >>>> Steve >>>> >>>> ------------------------------------------------------------------------ >>>> From: Ken Laskey [mailto:klaskey@mitre.org] >>>> Sent: 04 September 2005 21:22 >>>> To: Chiusano Joseph >>>> Cc: SOA-RM >>>> Subject: Re: [soa-rm] Amazon.com >>>> <http://Amazon.com> and Hurricane Catrina - >>>> Service Context? Service "Veneer"? >>>> >>>> Apple also did this with their iTunes Music >>>> Store: click the link and you order a donation >>>> instead of a song. >>>> >>>> This is why I keep insisting on >>>> differentiating between the service and the >>>> capability. The underlying capability is to >>>> collect money for a purpose. The service >>>> provides the interface for doing that. >>>> Typically, you invoke the capability through a >>>> service that enables you to buy a book (or a >>>> song) but a new service invokes that >>>> capability (with a new user facing interface >>>> for Apple; I haven't checked Amazon) to "buy" >>>> a donation. The power is the capability is >>>> reusable by making it accessible through a >>>> different service. >>>> >>>> Now note if I buy something through a service >>>> that allowed me to specify the UPC code, I >>>> could buy a donation through their existing >>>> service with that UPC, i.e. reusing the >>>> service for a purpose similar to but different >>>> from its original purpose. In fact, several >>>> supermarkets around here do support that >>>> because they have little tear-off tablets at >>>> the checkout for certain hunger organizations >>>> and you can hand the clerk a page for $1, $5, >>>> or $10. >>>> >>>> Many interesting variations and our RM just >>>> has to capture the concepts that can describe >>>> any of them. I think I'll mow the lawn and >>>> think about this some more. >>>> >>>> Ken >>>> >>>> On Sep 4, 2005, at 4:06 PM, Chiusano Joseph wrote: >>>> >>>> One thing that I discovered regarding the >>>> horrible catastrophe in the Southern US is >>>> that Amazon.com <http://Amazon.com> enabled >>>> people to use its online ordering service to >>>> make a donation. One could use the credit card >>>> information that Amazon.com >>>> <http://Amazon.com> already had online to make >>>> a donation in what it called "1-Click >>>> Donation" (or something similar). >>>> So instead of placing an order for a book, CD, >>>> etc., your "order" was your donation, and you >>>> could view your "order" online, which (as I >>>> recall) would show the amount that you donated. >>>> >>>> Something that came to my mind is: What would >>>> this placing of a "new face" on a existing >>>> service be called? Is it a different context >>>> for the ordering service? (i.e. in the context >>>> of Hurrican Katrina) Is it a "veneer" that was >>>> placed on top of the existing service? None of >>>> the above? >>>> >>>> Joe >>>> >>>> Joseph Chiusano >>>> Booz Allen Hamilton >>>> O: 703-902-6923 >>>> C: 202-251-0731 >>>> Visit us online@ http://www.boozallen.com >>>> <http://www.boozallen.com/> >>>> >>>> >>>> --- >>>> Ken Laskey >>>> MITRE Corporation, M/S H305 phone: 703-983-7934 >>>> 7515 Colshire Drive fax: 703-983-1379 >>>> McLean VA 22102-7508 >>>> >>>> >>>> >>>> This message contains information that may be >>>> privileged or confidential and is the property >>>> of the Capgemini Group. It is intended only >>>> for the person to whom it is addressed. If you >>>> are not the intended recipient, you are not >>>> authorized to read, print, retain, copy, >>>> disseminate, distribute, or use this message >>>> or any part thereof. If you receive this >>>> message in error, please notify the sender >>>> immediately and delete all copies of this message. >>>> >>>> >>>> >>>> >>>> --- >>>> Ken Laskey >>>> MITRE Corporation, M/S H305 phone: 703-983-7934 >>>> 7515 Colshire Drive fax: 703-983-1379 >>>> McLean VA 22102-7508 >>>> >>>> >>>> >>>> This message contains information that may be >>>> privileged or confidential and is the property >>>> of the Capgemini Group. It is intended only >>>> for the person to whom it is addressed. If you >>>> are not the intended recipient, you are not >>>> authorized to read, print, retain, copy, >>>> disseminate, distribute, or use this message >>>> or any part thereof. If you receive this >>>> message in error, please notify the sender >>>> immediately and delete all copies of this message. >>>> >>>> >>>> >>>> >>>> --- >>>> Ken Laskey >>>> MITRE Corporation, M/S H305 phone: 703-983-7934 >>>> 7515 Colshire Drive fax: 703-983-1379 >>>> McLean VA 22102-7508 >>>> >>>> >>>> >>>> >>>> This message contains information that may be >>>> privileged or confidential and is the property >>>> of the Capgemini Group. It is intended only >>>> for the person to whom it is addressed. If you >>>> are not the intended recipient, you are not >>>> authorized to read, print, retain, copy, >>>> disseminate, distribute, or use this message >>>> or any part thereof. If you receive this >>>> message in error, please notify the sender >>>> immediately and delete all copies of this message. >>>> -- >>>> --------------------------------------------------------------------------------- >>>> / Ken Laskey \ >>>> | MITRE Corporation, M/S H305 phone: 703-983-7934 | >>>> | 7515 Colshire Drive fax: 703-983-1379 | >>>> \ McLean VA 22102-7508 / >>>> ---------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> >> > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]