[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Re: Further Note on Mediator
Instead of pursuing a debate that your editors have already addressed (and for which detailed redrafts will shortly be provided and to which I hope you will reply in due course), could you guys turn your formidable talents to issues that haven't ? Peter F Brown Independent Consultant www.peterfbrown.com @pensivepeter +1.310.694.2278 Until 9 January: +32.472.027.812 Sent from my Windows Phone - Apologies for typos, levity and brevity - it's hard to type on a moving planet -----Original Message----- From: Hestand, Dan Sent: Friday, 17 December, 2010 17:53 To: rexb@starbourne.com Cc: Bashioum, Christopher D; mpoulin@usa.com; email@jamesodell.com; soa-rm-ra@lists.oasis-open.org Subject: RE: [soa-rm-ra] Re: Further Note on Mediator > Rex, > > Well, I wasn’t advocating redefining everything but at the very least we should be sure that the definitions we do provide are consistent with some stated abstraction level and where they are not, perhaps indicate that. It would go a long way in aiding adoption since the interpretation of the definitions would be less ambiguous (and you know there are going to be misinterpretations even if there were absolutely no ambiguity). > > As I said, it’s only my opinion and I threw it out to the group for consideration. I don’t have any desire to go redefine everything and certainly don’t want to spend 4+ more years doing so ;) But you do make a good point! > > Dan Hestand > Lead Software Systems Engineer > The MITRE Corp > 781.271.3755 > phestand@mitre.org > > From: Rex Brooks [mailto:rexb@starbourne.com] > Sent: Friday, December 17, 2010 11:31 AM > To: Hestand, Dan > Cc: Bashioum, Christopher D; mpoulin@usa.com; email@jamesodell.com; soa-rm-ra@lists.oasis-open.org > Subject: Re: [soa-rm-ra] Re: Further Note on Mediator > > This is exactly what I warned about. Get ready for another 4-5 years redefining everything. > > Cheers, > Rex > > On 12/16/10 1:20 PM, Hestand, Dan wrote: > Chris, > > Thanks for the explication. I didn’t make the point but you alluded to it at the end of your note, which is the level of abstraction is important contextual information for the definitions we provide. I don’t know if the abstraction level is fixed in the RAF but sometimes the discussions are at odds with each other because they are arrived at from differing abstraction levels. It would be nice to have some clearly defined level at which all definitions are made and explicitly make the point, if necessary, that these definitions may have different interpretations when viewed at another level. > > Dan Hestand > Lead Software Systems Engineer > The MITRE Corp > 781.271.3755 > phestand@mitre.org<mailto:phestand@mitre.org> > > From: Bashioum, Christopher D > Sent: Thursday, December 16, 2010 4:15 PM > To: mpoulin@usa.com<mailto:mpoulin@usa.com>; Hestand, Dan; email@jamesodell.com<mailto:email@jamesodell.com>; soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> > Subject: RE: [soa-rm-ra] Re: Further Note on Mediator > > I think that one could consider a mediator as having the following 2 properties: it is both a consumer and a provider, and sits between consumers and providers, and posesses these two properties at the same time. Although a service “is a form of mediation†as Dan said, it is really different than a mediator in that it is really more closely associated with a particular capability – and in general is does not sit between consumers and providers but between consumers and capabilities (here we distinguish the capability from the service). > > So, speaking loosely and conceptually, a mediator sits somewhere “in the middle†between a consumer and a service, and is itself both a consumer and a service at the same time, wherease a service sits much closer to the capability, and does not have another service between itself and the capability. So, in this case, an orchestration engine would be a mediator. > > All that being said – when we abstract things high enough, we come to Dan’s point and every service is a mediator. but when we come to a less abstract level, a mediator is a different kind of thing than a consumer or a provider. > > > From: mpoulin@usa.com<mailto:mpoulin@usa.com> [mailto:mpoulin@usa.com] > Sent: Thursday, December 16, 2010 3:15 PM > To: Hestand, Dan; email@jamesodell.com<mailto:email@jamesodell.com>; soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> > Subject: Re: [soa-rm-ra] Re: Further Note on Mediator > > So, do we really need to define Service Mediator based on Dan's 2 cents? What we gain or standardise with it if we do not say what it is and what it is not? > > - Michael > > -----Original Message----- > From: Hestand, Dan <phestand@mitre.org><mailto:phestand@mitre.org> > To: James Odell <email@jamesodell.com><mailto:email@jamesodell.com>; soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> <soa-rm-ra@lists.oasis-open.org><mailto:soa-rm-ra@lists.oasis-open.org> > Sent: Thu, Dec 16, 2010 7:42 pm > Subject: RE: [soa-rm-ra] Re: Further Note on Mediator > One thought that I’ll throw in is that a “service†is a form of mediation in the sense that the service interface mediates the interaction between a consumer and provider by transforming a consumer’s request into something intelligible for the provider. So to my mind the distinction is almost arbitrary. I do get that “mediation†is identified as a specific form of interaction but it seems that if we look hard enough we could call just about anything that is interposed between two interacting actors to facilitate the interaction, a “mediatorâ€. > > My 2cents worth… > > Dan Hestand > Lead Software Systems Engineer > The MITRE Corp > 781.271.3755 > phestand@mitre.org<mailto:phestand@mitre.org> > > From: James Odell [mailto:email@jamesodell.com<mailto:email@jamesodell.com?>] > Sent: Thursday, December 16, 2010 11:24 AM > To: soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> > Subject: Re: [soa-rm-ra] Re: Further Note on Mediator > > Have used word service to define a mediator, because I use the mediator as a kind of service — as such, it is a subclass of service, because it is a specialized form. > What differentiates it from a general service is that it provides a specialized functionality: i.e., a Mediator [actively] controls complex interactions based on complex relationship. > > -Jim > > > On 12/16/10 3:41 AM, "Lublinsky, Boris" indited: > With all these alphabet puns and money exchanges my questions remains unanswered. Here is the list: > •• Is mediator a service (Jim used the word service to define a mediator) > > •• If it is, why are we using both words – mediator and a service. What distinguishes mediator services from other services? > > •• If it is not, then what distinguishes it from the service? Size? Specific functionality? > > I think those are the base questions that we need to answer to lift this discussion from hand waiving to specifics. > > > From: James Odell [mailto:email@jamesodell.com] > Sent: Wednesday, December 15, 2010 4:46 PM > To: soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> > Subject: Re: [soa-rm-ra] Re: Further Note on Mediator > > Glad you appreciate alphabet puns. :-) > > Maybe, I should have said “controlâ€, instead of “manage.†> “Participate†has passive overtones, whereas “control†for a mediator would yield: > [actively] control complex interactions based on complex relationship. > > But, it’s not work splitting too many hairs. That’s what got SOA RM into trouble a few times. > > -Jim > > > On 12/15/10 5:33 PM, "mpoulin@usa.com"<mailto:mpoulin@usa.com> indited: > I value your humor, Jim: you say 'manage' + I say 'does not manage' > I say '1 p. (i.e. pence)' +you say 'Ruble' (where P is Russial 'R') > > - Michael > > > > -----Original Message----- > From: James Odell <email@jamesodell.com><mailto:email@jamesodell.com> > To: soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> > Sent: Wed, Dec 15, 2010 10:10 pm > Subject: Re: [soa-rm-ra] Re: Further Note on Mediator > > Michael, > > Your definition looks similar enough to mine, so it works for me. > > My 1/2 Ruble. > > -Jim > > > On 12/15/10 3:17 PM, "mpoulin@usa.com"<mailto:mpoulin@usa.com> indited: > From the time of GoF, mediator was never an managing entity, it always was a supporter of complex relationships between those who managed these relationships (and made them complex). I would strongly oppose an idea that a third party were managed my relationships until I hire this party for managing purposes. > > So, mediator, to me, is the one who realizes, provides complex interactions based on complex relationship, and nothing more. This is why I criticizes ESB system vendors for are crossing the line and taking over management. > > My 1p. > > - Michael > > > > -----Original Message----- > From: James Odell <email@jamesodell.com><mailto:email@jamesodell.com> > To: soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> <soa-rm-ra@lists.oasis-open.org><mailto:soa-rm-ra@lists.oasis-open.org> > Sent: Wed, Dec 15, 2010 7:23 pm > Subject: Re: [soa-rm-ra] Re: Further Note on Mediator > > Boris, > > For SOA and non-SOA implementations of agents: > A Mediator can be thought of as a service that offers functionalities that manage collaboration/interactions and act as an intermediary between entities. > With this definition, a mediator does not have to be software. If it does, then it would be a “software-based mediator.†> > My 2 cents. > > > -Jim > > > > > > On 12/15/10 1:42 PM, "Lublinsky, Boris" indited: > Thanks Jim. > The question then is where we should draw the line between services and mediators? > At which point a service becomes a mediator? Or in your mind they are the same? > > > > From: James Odell [mailto:email@jamesodell.com] > Sent: Wednesday, December 15, 2010 11:20 AM > To: soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> > Subject: Re: [soa-rm-ra] Re: Further Note on Mediator > > Boris, > > In my experience, using agent-based software, mediators are not necessarily “light weight†-- and they can be composite services, as well. In event-driven systems within SOA, this is particularly true. In large SOA systems, mediators are often employed as complex in service selection; for example, employing mediators as auction-based mechanisms (e.g., British auction, Dutch auction, Japanese auction, etc.). > > -Jim > > > > On 12/15/10 11:37 AM, "Lublinsky, Boris" indited: > Rex, > I am sorry, but this does not make sense. If we will continue this line of thought then every service is a mediator. > Mediator is typically a light weight component that doing on or more of following: > •• Data transformation to align data models mismatch > > •• Versioning support > > •• Routing based on external registry > > •• SLAs support, for example authorization > > •• Additional monitoring and load balancing > > Mediator is NOT a composite service implementation, which means that it does NOT: > •• Implement additional business functionality > > •• Orchestrate service execution > > > > From: Rex Brooks [mailto:rex.brooks@ncoic.org] > Sent: Wednesday, December 15, 2010 9:57 AM > To: rex.brooks@ncoic.org<mailto:rex.brooks@ncoic.org> > Cc: mpoulin@usa.com<mailto:mpoulin@usa.com>; danny_thornton2@yahoo.com<mailto:danny_thornton2@yahoo.com>; soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> > Subject: [soa-rm-ra] Re: Further Note on Mediator > > Hi again, > > I wanted to add one last clarificationof my opinion to the discussion on Mediator. I would support adding "orchestration conductor-controller software" as another example of a mediator. I only object to restricting the definition to such software. > > Cheers, > Rex > > On 12/13/10 9:31 AM, Rex Brooks wrote: > I think we are talking about different things when we use the word mediator. > > Let's discuss further. > > Cheers, > Rex > > On 12/9/10 11:57 AM, mpoulin@usa.com<mailto:mpoulin@usa.com> wrote: > Well, Rex, I also fail some times in convincing people in things that are obvious to me. > > > > This is not about voting because I also haven't quit yet. The time with judge. Four years ago, when I said that Web Services were not services, people looked at me like I was crazy; now, many look at people who still take WS as services like they are crazy... > > > > As you know, one fact can break any perfect theory; I am looking for such fact for you > > > > - Michael > > > -----Original Message----- > From: Rex Brooks <rexb@starbourne.com><mailto:rexb@starbourne.com> <mailto:rexb@starbourne.com> > To: mpoulin@usa.com<mailto:mpoulin@usa.com> > Cc: danny_thornton2@yahoo.com<mailto:danny_thornton2@yahoo.com>; soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> > Sent: Thu, Dec 9, 2010 3:58 pm > Subject: Re: [soa-rm-ra] Strawman of outstanding issues > > You haven't convinced me, Michael, > > So perhaps we'll have to just have a vote. > > BTW, I have never understood the tendency to insist on unanimous consensus. It's nice, yes, but not necessary. I lose a lot of votes across the spectrum of committees and organizations in which I participate, but I haven't quit yet. I believe we can survive some votes and if I'm on the losing side, I will be happy to accept it. > > Cheers, > Rex > > On 12/8/10 3:39 PM, mpoulin@usa.com<mailto:mpoulin@usa.com> wrote: > I understand that you had just a quick look at the article. > > > > Facade and Mediator are referred in different parts of the article and the only common things among them noted in the article is that both of them used incorrectly in the SOA Design Patterns book as well as in practice. > > > > Particularly, ESB as a Mediator has no rights to add any business functionality on the top of mediation agreed between consumer and service. If no mediation is explicitly agreed, no additions beside message routing are allowed in the ESB (according to RAF). Facade is "recommended" to be placed between service interface and the service, which is not only violates the definition of Facade as interface-interface transformation means but it makes no sense at all for SOA service (being in the mentioned position). > > > > > "mediated awareness" is a quality of the entities that are aware; awareness cannot belong to a 3rd party while 'awareness _about_ 3rd party' is a regular use of the term awareness. > > > > Registry-Repository cannot be a Mediator because, as you said, "Mediator is a behavioral pattern " and Registry-Repository doesn't have its own behavior regarding entities that use it, i.e. it cannot mediate between them. > > > > - Michael > > > > -----Original Message----- > From: Danny Thornton <danny_thornton2@yahoo.com><mailto:danny_thornton2@yahoo.com> <mailto:danny_thornton2@yahoo.com> > To: soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>; mpoulin@usa.com<mailto:mpoulin@usa.com> > Sent: Wed, Dec 8, 2010 10:17 pm > Subject: Re: [soa-rm-ra] Strawman of outstanding issues > > The text is using a third party Registry-Repository as one example of mediated awareness - there can be many ways to provide awareness. Mediator is a behavioral pattern and in this example the behavior is mediated awareness. As chair Ken mediates SC meetings, MatchMaker.com mediates people meeting each other, etc. > > The article in the link seems to use facade and mediator synonymously. Facade is structural. I have created many a facade for business logic and underlying data access. Facade tells me about an architectural structure. It may be that my facade is just a wrapper on entity beans to access DB tables in which case I would not denote it as a mediator in the architectural description. > > Danny > > --- On Wed, 12/8/10, mpoulin@usa.com<mailto:mpoulin@usa.com> <mpoulin@usa.com><mailto:mpoulin@usa.com> wrote: > > > From: mpoulin@usa.com<mailto:mpoulin@usa.com> <mpoulin@usa.com><mailto:mpoulin@usa.com> > Subject: Re: [soa-rm-ra] Strawman of outstanding issues > To: danny_thornton2@yahoo.com<mailto:danny_thornton2@yahoo.com>, boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>, soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>, peter@peterfbrown.com<mailto:peter@peterfbrown.com> > Date: Wednesday, December 8, 2010, 1:15 PM Danny, > I am really interested in reading your comments on my article "Patterns In The Context of SOA Business Services <http://www.infoq.com/articles/patterns-soa-business-services> " (http://www.infoq.com/articles/patterns-soa-business-services) > > A mediator MAY be known to service consumers and services/providers. Yes, you put this Mediator into the Service Description and, respectively, into the Services Contract, no problems. However, awareness and registry-repository have NOTHING to do with each other IMO while I have the same understanding of registry and repository as you describe. > > I believe that the statement "Mediated awareness promotes loose coupling by keeping the consumers and services from explicitly referring to each other and the descriptions" and "Mediation lets interaction vary independently" contradicts 90% of current RAF. In SOA, not in Web Services, consumer and service/provider MUST know each other ( as in Business ) to agree on the service use, to sign the Service Contract. > > Interaction between consumer and service MAY NOT be independent from them, it is not service orientation. Service registry/repository STORES information and nothing more. Consumers can use them or ignore them, it is up to them, we have no controls over them to enforce usage of registry/repository. Saying that re-direction via registry/repository is a good thing may be possible in only one case: participants of the consumer-service interaction are aware about such indirection. This is why I am saying that ESB pattern has been incorrectly represented in the form of ESB products. ESB may not hide interacting actors, it has only simplify this interaction. > > > - Michael > -----Original Message----- > From: Danny Thornton <danny_thornton2@yahoo.com><mailto:danny_thornton2@yahoo.com> > To: BorisLublinsky <boris.lublinsky@navteq.com><mailto:boris.lublinsky@navteq.com>; soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> <soa-rm-ra@lists.oasis-open.org><mailto:soa-rm-ra@lists.oasis-open.org>; Peter F Brown at work <peter@peterfbrown.com><mailto:peter@peterfbrown.com> > Sent: Wed, Dec 8, 2010 8:27 pm > Subject: RE: [soa-rm-ra] Strawman of outstanding issues > Within the context of the SOA RAF, Section 4.2: > > Service consumers <http://us.mc556.mail.yahoo.com/mc/welcome?.gx=1&.tm=1291827748&.rand=er2um5167fcag#ServiceConsumer> and service providers may have direct awareness or mediated awareness where mediated awareness is achieved through some third party. > > A common mechanism for mediated awareness is a registry-repository. The registry stores links or pointers to service description artifacts. The repository in this example is the storage location for the service description artifacts. > > Mediated awareness promotes loose coupling by keeping the consumers and services from explicitly referring to each other and the descriptions. Mediation lets interaction vary independently. > > > --- On Wed, 12/8/10, Peter F Brown at work <peter@peterfbrown.com<mailto:peter@peterfbrown.com> <http://us.mc556.mail.yahoo.com/mc/compose?to=peter@peterfbrown.com> > wrote: > > > From: Peter F Brown at work <peter@peterfbrown.com<mailto:peter@peterfbrown.com> <http://us.mc556.mail.yahoo.com/mc/compose?to=peter@peterfbrown.com> > > Subject: RE: [soa-rm-ra] Strawman of outstanding issues > To: "Lublinsky, Boris" <boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com> <http://us.mc556.mail.yahoo.com/mc/compose?to=boris.lublinsky@navteq.com> >, "soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> <http://us.mc556.mail.yahoo.com/mc/compose?to=soa-rm-ra@lists.oasis-open.org> " <soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> <http://us.mc556.mail.yahoo.com/mc/compose?to=soa-rm-ra@lists.oasis-open.org> > > Date: Wednesday, December 8, 2010, 12:09 PM So registry is also a service but not part of 'the' service that is playing the role of provider? Is it a service performing a different role? It's capability offering being rather specialized (eg service discovery)? Going back to the model, is it simply another (of potentially many) role played by a participant in the ecosystem? > > Peter F Brown > Independent Consultant > www.peterfbrown.com<http://www.peterfbrown.com> <http://www.peterfbrown.com> <http://www.peterfbrown.com/> > @pensivepeter > +1.310.694.2278 > > Sent from my Windows Phone - Apologies for typos, levity and brevity - it's hard to type on a moving planet > ________________________________ > > From: Lublinsky, Boris > Sent: Wednesday, 08 December, 2010 6:48 > To: peter@peterfbrown.com<mailto:peter@peterfbrown.com> <http://us.mc556.mail.yahoo.com/mc/compose?to=peter@peterfbrown.com> ; soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> <http://us.mc556.mail.yahoo.com/mc/compose?to=soa-rm-ra@lists.oasis-open.org> > Subject: RE: [soa-rm-ra] Strawman of outstanding issues > > > > > Peter, > > This is a good deck. > > A couple of comments: > > > > > > > > Mediator > > > > > > > > -? is a registry a good example? Do we have better ones? Is it more than mediator? > > I do not consider a registry to be a mediator. A registry is a specialized entity in his own right with its own set of goals. > > Typically a mediator is an entity that is invoking service on behalf as a consumer and is seen by consumer as a service (compare to proxy in a distributed system). The difference between mediator and a simple proxy is significant - mediator is more like an interpreter in a conversation between people speaking different languages. Typical mediators do the following - transport transformation (for example MOM to HTTP), semantic alignment (data transformation), dynamic routing, often leveraging registry (version-based routing, etc) > > > > I am not sure how Skill is relevant for SOA > > > > I have a real issue with introducing resources into SOA. The problem is Resources are orthogonal to services - it is a completely different model of the world - see REST vs SOA. A service implementation internally does depend on resources, but this is opaque to the service consumer. > > The issue here is that SOA is based on the functional decomposition, where functions can cross resource boundaries, where Resource decomposition is based on identifying resources, regardless of services they provide. A system can be build either way, but those will be 2 different systems. The relationship is similar to entity beans (resource) vs session beans (services). > > > > Semantics is a really hard one. The issue is that in SOA semantics is defined by service provider. It is NOT specific to a consumer/provider pair. A service consumer can have his own semantics, but he typically has to use a mediator for resolving semantic differences > > > > > > From: Peter F Brown [mailto:peter@peterfbrown.com <http://us.mc556.mail.yahoo.com/mc/compose?to=peter@peterfbrown.com&> ] > > Sent: Tuesday, December 07, 2010 8:09 PM > > To: soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> <http://us.mc556.mail.yahoo.com/mc/compose?to=soa-rm-ra@lists.oasis-open.org> > > Subject: [soa-rm-ra] Strawman of outstanding issues > > > > Hi: > > We have worked through the entirety of outstanding issues, questions and concerns for section 3 (along the way, examining also sections 1 & 2). We have, inevitably many, many, edits to propose! > > > > However, and as promised on last week's call, we now present a "Strawman", in the form of the attached slide deck which we think touches on all the main issues and provides a narrative for addressing them. > > > > We stress this is not an editing exercise but an attempt to gain consensus on the main issues, definitions and relationships between terms before the proceeding with presenting detailed dispositions of textual changes, in line with said consensus. > > > > As previously announced, I will not be able to join the call tomorrow as I'll be some 30,000 feet over Kansas at the time of the call. Chris Bashioum will lead off as your Maître d' > > > > Regards, > > Peter > > > > Peter F Brown > > Independent Consultant > > [cid:image001.png@01CB96AC.EA7AD190 <http://us.mc556.mail.yahoo.com/mc/compose?to=image001.png@01CB96AC.EA7AD190> ] > > Transforming our Relationships with Information Technologies > > www.peterfbrown.com<http://www.peterfbrown.com> <http://www.peterfbrown.com> <http://www.peterfbrown.com/> > > @pensivepeter<" target=_blank rel=nofollowhttp://twitter.com/#!/@pensivepeter> <http://twitter.com/#%21/@pensivepeter> ; > > P.O. Box 49719, Los Angeles, CA 90049, USA > > Tel: +1.310.694.2278 > > > > > > > > The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > ________________________________ > > The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. > > > ________________________________ > The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. > > > > -- > > Rex Brooks > > President, CEO > > Starbourne Communications Design > > GeoAddress: 1361-A Addison > > Berkeley, CA 94702 > > Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
