Michael,
If what we are saying is that a mediator is a components (remotable)
that implements non business functionality (for me orchestration is business)
that simplifies usage of the service,
I am fine
What kinda upsets me is when we are saying that a mediator is a
specialized service, because this starts to blur things.
From: mpoulin@usa.com
[mailto:mpoulin@usa.com]
Sent: Thursday, December 16, 2010 4:31 AM
To: klaskey@mitre.org; email@jamesodell.com;
soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Re: Further Note on Mediator
Ken,
"semantic/data model
mediation" in the form of mapping or translation may be a good
servicer, no objections here. The question is should this service be an
attribute of physical Mediator or stand-alone. I vote for the latter.
My reason is that Mediator is a transmitter of the relationship/interaction
logic between participating parties. While Mediator is in position of
modifying the information on the fly, it should not do this until it becomes
a legitimate part of the business transduction (vs.
magic technical manipulations in the depth of IT).
Can a Mediator be a service? If it carries particular Business
Function, yes, it can, IMO. In this case, I revoke Mediator from the exclusive
ownership of IT and put it into the business domain.
Boris, does this fit with your view?
- Michael
-----Original Message-----
From: Ken Laskey <klaskey@mitre.org>
To: mpoulin@usa.com; email@jamesodell.com; soa-rm-ra@lists.oasis-open.org
Sent: Thu, Dec 16, 2010 2:13 am
Subject: RE: [soa-rm-ra] Re: Further Note on Mediator
I understand your concern. In common usage around my
sponsors, the idea of semantic/data model mediation is well accepted.
True, this typically encapsulates certain business logic and is not magic by an
ESB. OTOH, we can certainly have well-constructed and well-documented
services that perform this type of translation and it is not unreasonable to
consider this as mediation.
---------------------------------------------------------------------------
MITRE Corporation, M/S
H305
phone: 703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
if a consumer deals with a business service (which includes
manual/human and technical parts), this deal is realised in the form of
business transaction. If a mediating intermediary belongs to IT and does
not have business responsibilities, it may not control or manage even technical
parts of the business transaction. So, there are 3 choices for the
intermediary: 1) take particular business responsibilities and become a partner
in the transaction; 2) become a part of consumer; 3) become a part of service (and,
thus, hide behind their business responsibilities).
I am so picky here because we already have a precedent that causes
business problems - ESB systems. Companies like Microsoft and even some people
in IBM insist that ALL interactions between ALL consumers and services MUST go
through the ESB, and ESB can modify and enrich data w/o business
being informed. If so, in a little wile, the ESB becomes 'a heart' of the
company - no business transactions can happen w/o it. This is good for vendors
but bad for clients: any new version of the ESB can put the company on its
knees.
So, a mediator may mediate - support, provide, simplify,
accelerate, etc., but not manage, control, manipulate, modify, translate etc.
the interaction mechanics. [Translation of data models is, actually a
difficult thing: consumer and service must understand what information they
exchange, this understanding is documented in the Service Contract. None of
them should not send something out that the counterpart does not understand: if
a translator is needed, it must be explicitly hired by the
participant and specified in the Service Contract.]
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" 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>
To: 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" 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>
To: soa-rm-ra@lists.oasis-open.org
<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
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
Cc: mpoulin@usa.com;
danny_thornton2@yahoo.com;
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 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>
To: mpoulin@usa.com
Cc: danny_thornton2@yahoo.com;
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 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>
To: soa-rm-ra@lists.oasis-open.org;
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 <mpoulin@usa.com>
wrote:
From: mpoulin@usa.com
<mpoulin@usa.com>
Subject: Re: [soa-rm-ra] Strawman of outstanding issues
To: danny_thornton2@yahoo.com, boris.lublinsky@navteq.com,
soa-rm-ra@lists.oasis-open.org,
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>
To: BorisLublinsky <boris.lublinsky@navteq.com>; soa-rm-ra@lists.oasis-open.org
<soa-rm-ra@lists.oasis-open.org>;
Peter F Brown at work <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
<http://us.mc556.mail.yahoo.com/mc/compose?to=peter@peterfbrown.com>
> wrote:
From: Peter F Brown at work <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
<http://us.mc556.mail.yahoo.com/mc/compose?to=boris.lublinsky@navteq.com>
>, "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 <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/>
@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
<http://us.mc556.mail.yahoo.com/mc/compose?to=peter@peterfbrown.com>
; 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 <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/>
> @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.
|