[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Loose Coupling
The original definition was: "A SOA Fabric is an abstract concept to represent the environment in which a service within a service-oriented system resides, is discovered, is invoked, and is evolved." Using "service-oriented environment" instead of "service-oriented system" will yield the following (please note also the change of "evolved" to "managed"): "A SOA Fabric is an abstract concept to represent the environment in which a service within a service-oriented environment resides, is discovered, is invoked, and is managed." Which is an awkward double-use of "environment". Suggested new version, which removes "within a service-oriented environment": "A SOA Fabric is an abstract concept to represent the environment in which a service resides, is discovered, is invoked, and is managed." Who likey? Joe Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Friday, May 20, 2005 6:25 PM > Cc: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Loose Coupling > > That is the term I have favored too. > > From the charter: > > *Reference Model *- A reference model is an abstract > framework for understanding significant relationships among > the entities of some environment, and for the development of > consistent standards or specifications supporting that environment. > > +1 > > D > > Christopher Bashioum wrote: > > > I like that better > > > > > -------------------------------------------------------------- > ---------- > > *From:* Smith, Martin [mailto:Martin.Smith@DHS.GOV] > > *Sent:* Friday, May 20, 2005 6:16 PM > > *To:* Christopher Bashioum; soa-rm@lists.oasis-open.org > > *Subject:* RE: [soa-rm] Loose Coupling > > > > “Environment”? > > > > > > > > Martin > > > > > > > > > > > > -----Original Message----- > > *From:* Christopher Bashioum [mailto:cbashioum@mitre.org] > > *Sent:* Friday, May 20, 2005 1:44 PM > > *To:* soa-rm@lists.oasis-open.org > > *Subject:* RE: [soa-rm] Loose Coupling > > > > > > > > Joe, > > > > > > > > I am uncomfortable with the term "system" - as that strikes me > > as more concrete than architecture. Did we really agree to use > > that term? If so, I guess I just read past that earlier - maybe > > while focusing on some other point. > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > *From:* Chiusano Joseph [mailto:chiusano_joseph@bah.com] > > *Sent:* Friday, May 20, 2005 10:19 AM > > *To:* soa-rm@lists.oasis-open.org > > *Subject:* RE: [soa-rm] Loose Coupling > > > > A service-oriented system is a system that is based on SOA > > principles. I used the term "SOA-based system" a while back, > > and Duane recommended using "service-oriented system". > > "Evolved" instead of "managed" is fine with me. > > > > > > > > Thanks, > > > > Joe > > > > > > > > Joseph Chiusano > > > > Booz Allen Hamilton > > > > Visit us online@ http://www.boozallen.com > > <http://www.boozallen.com/> > > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > *From:* Christopher Bashioum > [mailto:cbashioum@mitre.org] > > *Sent:* Friday, May 20, 2005 9:55 AM > > *To:* soa-rm@lists.oasis-open.org > > *Subject:* RE: [soa-rm] Loose Coupling > > > > Joe, > > > > > > > > what is a "service oriented system?". Also, I would be > > more comfortable with the definition if you dropped the > > word 'evolved' and added the word 'managed'. > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > *From:* McGregor.Wesley@tbs-sct.gc.ca > > [mailto:McGregor.Wesley@tbs-sct.gc.ca] > > *Sent:* Friday, May 20, 2005 9:47 AM > > *To:* chiusano_joseph@bah.com; > soa-rm@lists.oasis-open.org > > *Subject:* RE: [soa-rm] Loose Coupling > > > > Joe, > > > > > > > > Your definition seems reasonable. > > > > > > > > Wes > > > > -----Original Message----- > > *From:* Chiusano Joseph > [mailto:chiusano_joseph@bah.com] > > *Sent:* May 19, 2005 10:37 PM > > *To:* soa-rm@lists.oasis-open.org > > *Subject:* RE: [soa-rm] Loose Coupling > > > > > > > > Can someone please provide what they believe to be a > > definition of "SOA Fabric"? By this I don't mean "I > > don't know what it is so I am seeking meaning", but > > rather "I am not sure that we are all in semantic > > alignment/agreement for this term". > > > > > > > > I will start with my definition: "A SOA Fabric is an > > abstract concept to represent the > environment in which > > a service within a service-oriented system > resides, is > > discovered, is invoked, and is evolved." > > > > > > > > Please poke lots of holes in it.:) > > > > > > > > Joe > > > > > > > > P.S. I didn't even get into the notion of a "SOA > > Fabric Softener":p > > > > > > > > Kind Regards, > > > > Joseph Chiusano > > > > Booz Allen Hamilton > > > > Visit us online@ http://www.boozallen.com > > <http://www.boozallen.com/> > > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > *From:* Rex Brooks [mailto:rexb@starbourne.com] > > *Sent:* Thursday, May 19, 2005 10:15 PM > > *To:* Hamid Ben Malek; Michael Stiefel; > > soa-rm@lists.oasis-open.org > > *Subject:* RE: [soa-rm] Loose Coupling > > > > I don't actually intend to get into this, > but I wanted > > to point out, Hamid, that you are assuming or > > presuming that we all go along with concept > of an SOA > > Fabric as the best, or even one of the > contenders for > > the best working description and governance > model for > > SOA. I don't happen to subscribe to that viewpoint, > > nor do I subscribe to the Enterprise Service Bus > > Model. However, there are important concepts and > > modeling elements within both of those schools of > > thought on SOA with which I do agree and have every > > intention of adopting for myself, whether or not the > > TC decides to include those concepts in the > Reference > > Model. As for loose-coupling, I consider it one of > > those options best described in a primer or > as part of > > a user guide or implementation guide, as a > > best-practice recommendation just because it is more > > flexible. > > > > > > > > That doesn't mean that I think all tightly coupled > > SOAs will be inferior, just more limited > and difficult > > to work with. > > > > > > > > Ciao, > > > > Rex > > > > > > > > I would encourage folks to have a look at > > > > > > > > At 6:17 PM -0700 5/19/05, Hamid Ben Malek wrote: > > > > Michael, > > > > You have a good analysis; however, you are missing > > many points. I unfortunately cannot explain this > > clearly by email because it needs few pages of > > verbosity. I certainly hope I will have > time to write > > a good article in which I explain these > things. I just > > hope to make the deadline for spec review (next > > Wednesday) and submit the article along with my > > reviews included in the spreadsheet. Let me try here > > to summarize the points you are missing in your > > analysis below: > > > > > > > > I believe that in your analysis, the concept of > > "loose-coupling" is not well understood in its right > > context. When we talk about loose-coupling > in SOA, it > > refers to a much strict concept that > touches directly > > the boundaries of the services and the service > > consumers. If the coupling remains inside the SOA > > Fabric and does not directly touch a > service and/or a > > service consumer, this kind of coupling is not a > > "coupling" in the context of SOA. For example, when > > you talk about "policy requirements" and > things alike, > > these concepts are actually handled by the > SOA Fabric > > and not directly by a service and/or a service > > consumer in the sense that the implementation of it > > may have to change or accommodate in a > certain way to > > ensure interoperability. The third principle of SOA > > (about "Contracts and Schemas") is really > ensuring the > > strict concept of "loose-coupling" by pushing any > > other types of couplings to the SOA Fabric which is > > able to handle to job and take off the work > load from > > service consumers by using data transformations. > > > > > > > > Regards, > > > > > > > > Hamid. > > > > > > > > > > > > -----Original Message----- > > From: Michael Stiefel > > [mailto:development@reliablesoftware.com] > > Sent: Thursday, May 19, 2005 5:37 PM > > To: soa-rm@lists.oasis-open.org > > Subject: [soa-rm] Loose Coupling > > > > > > > > While I agree that in general loose coupling is good > > in a SOA, the > > > > definition of a SOA should not include > loose coupling. > > > > > > > > Loose coupling is a design attribute, and > therefore a > > concrete not an > > > > abstract attribute. It is also a question of degree. > > How much loose > > > > coupling you have is a tradeoff among various design > > factors. > > > > > > > > In theory you could have a tightly coupled SOA. How? > > If the policy > > > > requirements of the service were so rigid, > and tightly > > patterned after many > > > > implementation details, I would consider that a > > tightly coupled SOA. > > > > > > > > However, our SOA RM should include the idea of > > multiple services and the > > > > appropriate abstract attributes that go along with > > that. I would think we > > > > could then use that as a reference point to > talk about > > how tightly coupled > > > > a particular concrete architecture would be. > > > > > > > > Michael > > > > > > > > > > > > At 07:48 PM 5/19/2005, Don Flinn wrote: > > > >>Hamid > > > >> > > > >>I agree with your differences between the older > > distributed models, > > > >>where CORBA is an example, BUT I believe that some of > > the members of the > > > >>TC would reject them for inclusion in the RM as being > > too concrete. For > > > >>example, loose-coupling has been rejected by some > > members as being too > > > >>concrete a concept. IMHO this is one of the > > distinguishing features > > > >>that differentiate an SOA from the previous > > distributed systems. > > > >> > > > >>Don > > > >> > > > >>On Thu, 2005-05-19 at 15:46 -0700, Hamid Ben Malek wrote: > > > >> > Frank, > > > >> > > > > >> > Using Matt's expression, Corba could be put in the > > category of "OO + > > > >> > extra things". Corba is Object-Oriented, has > > discovery services, > > > >> > interfaces, language neutral, a communication bus, > > and so many other > > > >> > features. However, Corba is definitely NOT SOA. > > Why? There are many > > > >> > reasons for this. It suffices to only cite one > > reason which is related > > > >> > to the third SOA principle (⤦Contracts and > > Schemasâ¤ù). Corba does not > > > >> > satify the third principle (actually it does not > > satify other > > > >> > principles too). Corba is RPC-based, and the > > message that goes inside > > > >> > the wire is a binary OO-RPC call. The limitations > > of OO-RPC calls for > > > >> > applications that go beyond the enterprise scope > > are well known > > > >> > (problems related to very tight-coupling, > > versioning problems, etc⤆). > > > >> > The third principle in SOA roughly states that the > > calls between SOA > > > >> > services and between a client and an SOA service > > are all XML messages > > > >> > and that only the contrats and schemas are shared > > between services and > > > >> > clients (no RPC interfaces such as those described > > in Corba by IDL, or > > > >> > other OO artifats). The third principle ensures > > loose-coupling through > > > >> > the use of contracts and schemas. This is not the > > case in Corba. > > > >> > > > > >> > > > > >> > > > > >> > Regards, > > > >> > > > > >> > > > > >> > > > > >> > Hamid. > > > >> > > > > >> > > > > >> > > > > >> > -----Original Message----- > > > >> > From: Francis McCabe [mailto:fgm@fla.fujitsu.com] > > > >> > Sent: Thursday, May 19, 2005 2:43 PM > > > >> > To: Don Flinn > > > >> > Cc: SOA-RM > > > >> > Subject: Re: [soa-rm] SOA System > > > >> > > > > >> > > > > >> > > > > >> > Well, > > > >> > > > > >> > I wasn't aware that CORBA name servers had > > anything other than > > > >> > > > > >> > IDLs in them; but be that as it may .... > > > >> > > > > >> > Is there a problem in recasting CORBA as an SOA? > > Or casting SOA > > > >> > as > > > >> > > > > >> > distributed computing? > > > >> > > > > >> > > > > >> > > > > >> > There will be many factors that affect > > scalability in the design > > > >> > > > > >> > of an architecture. The service-orientedness is > > just one of those > > > >> > > > > >> > factors. To paraphrase an old maxim, there are few > > ways to be > > > >> > > > > >> > scalable and many ways to be fragile:) > > > >> > > > > >> > > > > >> > > > > >> > I.e., SOA is one property of an architecture - > > the focus on > > > >> > public > > > >> > > > > >> > interactions etc. etc. To model that we need > > descriptions, semantics > > > >> > > > > >> > etc. > > > >> > > > > >> > To build a high-class SOA, we will need to > > consider other things; > > > >> > > > > >> > and we will need to apply the SOA RM to the > > architecture. > > > >> > > > > >> > > > > >> > > > > >> > Clear as mud, I guess, as my 'ole pappy used to say. > > > >> > > > > >> > Frank > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > On May 19, 2005, at 2:30 PM, Don Flinn wrote: > > > >> > > > > >> > > > > >> > > > > >> > > Hi Frank > > > >> > > > > >> > > > > > >> > > > > >> > > My point was not to discuss CORBA's problems or > > lack of such. (I > > > >> > was > > > >> > > > > >> > > one of the OMG/CORBA specification chairs during > > CORBA'S hay- > > > >> > days :-) > > > >> > > > > >> > > But to ask at what level of abstraction does our > > RM specify that > > > >> > which > > > >> > > > > >> > > makes it a reference model for an SOA. I know > > that an SOA is > > > >> > > > > >> > > different > > > >> > > > > >> > > from previous distributed models, but what > > qualities in our abstract > > > >> > > > > >> > > model do we discuss that makes it different from > > a specification of > > > >> > a > > > >> > > > > >> > > generic distributed model. > > > >> > > > > >> > > > > > >> > > > > >> > > You mentioned "the focus on the public > > description of things". Is > > > >> > > > > >> > > this > > > >> > > > > >> > > the only thing that makes an SOA different and > > what our reference > > > >> > > > > >> > > model > > > >> > > > > >> > > should discuss? Even there, again using poor old > > CORBA, at an > > > >> > > > > >> > > abstract > > > >> > > > > >> > > level the CORBA naming service is a public > > description of things. > > > >> > > > > >> > > > > > >> > > > > >> > > What I'm driving at and what we all are trying to > > grapple with is > > > >> > > > > >> > > where > > > >> > > > > >> > > on the abstract spectrum should we be. At one > > extreme, one enters > > > >> > the > > > >> > > > > >> > > world of metaphysics and the question become > > "What is the meaning of > > > >> > > > > >> > > life :-)" My question is simpler, maybe. Where > > on the abstract > > > >> > > > > >> > > spectrum > > > >> > > > > >> > > should we be to model an SOA as opposed to any > > distributed model? I > > > >> > > > > >> > > don't believe that we can produce a usable > > specification if the > > > >> > > > > >> > > model is > > > >> > > > > >> > > abstracted to such a high level that we are > > delivering a reference > > > >> > > > > >> > > model > > > >> > > > > >> > > for any distributed computing model. > > Specifically, what are the > > > >> > > > > >> > > abstract qualities that distinguish an SOA from a > > generic > > > >> > distributed > > > >> > > > > >> > > model? > > > >> > > > > >> > > > > > >> > > > > >> > > Don > > > >> > > > > >> > > > > > >> > > > > >> > > On Thu, 2005-05-19 at 10:57 -0700, Francis McCabe > > wrote: > > > >> > > > > >> > > > > > >> > > > > >> > >> And the problem is .... > > > >> > > > > >> > >> > > > >> > > > > >> > >> I think that CORBA's problems did not come at > > this level of > > > >> > > > > >> > >> abstraction, but in the low-level realization. > > E.g., IDL is C++ in > > > >> > a > > > >> > > > > >> > >> different syntax. It is rigid, and not capable > > of incorporating > > > >> > > > > >> > >> descriptions of policies, etc. > > > >> > > > > >> > >> > > > >> > > > > >> > >> SOA *is* different from random distributed > > computing, because of > > > >> > the > > > >> > > > > >> > >> focus on public descriptions of things. > > > >> > > > > >> > >> > > > >> > > > > >> > >> Frank > > > >> > > > > >> > >> > > > >> > > > > >> > >> > > > >> > > > > >> > >> On May 19, 2005, at 10:20 AM, Don Flinn wrote: > > > >> > > > > >> > >> > > > >> > > > > >> > >> > > > >> > > > > >> > >>> To All > > > >> > > > > >> > >>> > > > >> > > > > >> > >>> As we abstract and restrict our reference > > model, I begin to wonder > > > >> > > > > >> > >>> what > > > >> > > > > >> > >>> makes this reference model a SOA reference > > model as opposed to say > > > >> > a > > > >> > > > > >> > >>> CORBA reference model. CORBA had interfaces as > > one of its primary > > > >> > > > > >> > >>> constructs and had a specific language, IDL, to > > define the > > > >> > > > > >> > >>> interfaces. > > > >> > > > > >> > >>> The interfaces were the external front-end to > > Impls, which at our > > > >> > > > > >> > >>> level > > > >> > > > > >> > >>> of abstraction were the same as services and > > CORBA had the notion > > > >> > of > > > >> > > > > >> > >>> metadata. It also had a Discovery & Advertise > > entity, the naming > > > >> > > > > >> > >>> service. This comparison is not limited to > > CORBA, but could > > > >> > include > > > >> > > > > >> > >>> DCE, DCOM, J2EE, etc. to a greater or lesser > > extent. So my > > > >> > > > > >> > >>> question is; > > > >> > > > > >> > >>> At the level of abstraction that we are going, > > what makes our > > > >> > > > > >> > >>> reference > > > >> > > > > >> > >>> model a SOA reference model and not a generic > > distributed > > > >> > computing > > > >> > > > > >> > >>> model? If the answer is the latter, is this > > what the world is > > > >> > > > > >> > >>> expecting > > > >> > > > > >> > >>> from us? > > > >> > > > > >> > >>> > > > >> > > > > >> > >>> Don > > > >> > > > > >> > >>> > > > >> > > > > >> > >>> On Thu, 2005-05-19 at 09:10 -0700, Francis > > McCabe wrote: > > > >> > > > > >> > >>> > > > >> > > > > >> > >>> > > > >> > > > > >> > >>>> Matt, et. al. > > > >> > > > > >> > >>>> In case this thought has not been raised in > > future > > > >> > emails ... :) > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> I believe that I am correct in stating that, > > in practice, the > > > >> > > > > >> > >>>> best > > > >> > > > > >> > >>>> aspects of languages like Java is not features > > such as > > > >> > inheritance > > > >> > > > > >> > >>>> but the ease with which applications can be > > slotted together. > > > >> > > > > >> > >>>> The key > > > >> > > > > >> > >>>> feature that enables this Lego®-style > > assembly is the > > > >> > > > > >> > >>>> *interface*. It > > > >> > > > > >> > >>>> turns out that interfaces make the task of > > programming large > > > >> > > > > >> > >>>> systems > > > >> > > > > >> > >>>> significantly easier. > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> The logical development of the type-only > > interface is the > > > >> > > > > >> > >>>> *semantic* interface. But in any case, modern > > SOAs represent one > > > >> > > > > >> > >>>> aspect of the trend towards focusing on > > interfaces as a way of > > > >> > > > > >> > >>>> controlling complexity and enabling rapid > > > >> > development/deployment > > > >> > > > > >> > >>>> etc. > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> So, at one level of abstraction, it may be > > useful to think of > > > >> > > > > >> > >>>> SOAs > > > >> > > > > >> > >>>> as a system of interfaces that allow > > architectures to be crossed, > > > >> > > > > >> > >>>> ownership domains to be crossed, different > > implementation > > > >> > languages > > > >> > > > > >> > >>>> to be used, different versions to coexists, > > etc. etc. > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> Our task is to try to pick out the keystones > > that bear the SOA > > > >> > > > > >> > >>>> hallmark; which seem to me to be what we have: > > services as > > > >> > *action > > > >> > > > > >> > >>>> boundaries*, semantic interfaces, tons of > > descriptions. > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> Frank > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> On May 18, 2005, at 7:22 PM, Matthew MacKenzie > > wrote: > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>>> Michael, > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>> On 18-May-05, at 5:55 PM, Michael Stiefel wrote: > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>>> Matt, re your comment that "SO is OO, > > basically, with some > > > >> > value- > > > >> > > > > >> > >>>>>> add infrastructure such as discovery and > > description." > > > >> > > > > >> > >>>>>> > > > >> > > > > >> > >>>>>> Now this raises an interesting point in our > > definition of > > > >> > service > > > >> > > > > >> > >>>>>> abstraction. Normally people cite as one of > > the differences > > > >> > > > > >> > >>>>>> between SO and OO the fact that the former > > is more loosely > > > >> > > > > >> > >>>>>> coupled. > > > >> > > > > >> > >>>>>> > > > >> > > > > >> > >>>>>> Would you maintain that OO systems that can > > work with wire > > > >> > > > > >> > >>>>>> formats > > > >> > > > > >> > >>>>>> of object systems (such as COM and CORBA) > > that allowed runtime > > > >> > > > > >> > >>>>>> dynamic binding of heterogenous systems fall > > into the SO > > > >> > > > > >> > >>>>>> category? > > > >> > > > > >> > >>>>>> > > > >> > > > > >> > >>>>>> > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>> I maintain that in certain situations that > > they *could* fall > > > >> > into > > > >> > > > > >> > >>>>> the SO category. I think that the "loosely > > coupled" argument is > > > >> > > > > >> > >>>>> sort of weak, because I am not completely > > certain that even > > > >> > things > > > >> > > > > >> > >>>>> like web services end up creating loosely > > coupled systems! > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>>> > > > >> > > > > >> > >>>>>> Or do you see looser coupling as a useful > > feature that is much > > > >> > > > > >> > >>>>>> more easily achieved with newer > > implementation technologies > > > >> > such > > > >> > > > > >> > >>>>>> as Web services, and therefore have nothing > > to do with SO. > > > >> > > > > >> > >>>>>> > > > >> > > > > >> > >>>>>> > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>> I love loose coupling...but yeah, I do just > > view it as "a good > > > >> > > > > >> > >>>>> thing", and not a necessary element of SOA. > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>> -matt > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>>> > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>>> > > > >> > > > > >> > >>> -- > > > >> > > > > >> > >>> Don Flinn > > > >> > > > > >> > >>> President, Flint Security LLC > > > >> > > > > >> > >>> Tel: 781-856-7230 > > > >> > > > > >> > >>> Fax: 781-631-7693 > > > >> > > > > >> > >>> e-mail: flinn@alum.mit.edu > > > >> > > > > >> > >>> http://flintsecurity.com > > > >> > > > > >> > >>> > > > >> > > > > >> > >>> > > > >> > > > > >> > >>> > > > >> > > > > >> > >> > > > >> > > > > >> > >> > > > >> > > > > >> > >> > > > >> > > > > >> > > -- > > > >> > > > > >> > > Don Flinn > > > >> > > > > >> > > President, Flint Security LLC > > > >> > > > > >> > > Tel: 781-856-7230 > > > >> > > > > >> > > Fax: 781-631-7693 > > > >> > > > > >> > > e-mail: flinn@alum.mit.edu > > > >> > > > > >> > > http://flintsecurity.com > > > >> > > > > >> > > > > > >> > > > > >> > > > > > >> > > > > >> > > > > >>-- > > > >>Don Flinn > > > >>President, Flint Security LLC > > > >>Tel: 781-856-7230 > > > >>Fax: 781-631-7693 > > > >>e-mail: flinn@alum.mit.edu > > > >>http://flintsecurity.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]