Surre, specific technology here is to demonstrate the consequences of inaccurate definition such as 'mediater controls'. Mediator may control only message routing and this narrowd definition does not leave room for mistakes and misinterpretation.
- Michael
-----Original Message-----
From: Rex Brooks <>
To:
Cc: ;
Sent: Thu, Dec 16, 2010 4:35 pm
Subject: Re: [soa-rm-ra] Re: Further Note on Mediator
Even if the issue of mediator were open, this would be far more
depth than a foundational work should specify in my opinion.
We make it clear early on that specific technologies are not in
scope for this work.
Cheers,
Rex
On 12/15/10 5:02 PM, wrote:
All right, I
wished we could avoid this thing going deeper. In http://www.infoq.com/articles/patterns-soa-business-services , I have
explained my Business SOA concerns about a mediator, which
controls.
In
3 lines:
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.]
-
Michael
-----Original Message-----
From: James Odell <>
To:
Sent: Wed, Dec 15, 2010 10:46 pm
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, ""
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 <>
To:
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, ""
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 <>
To:
<>
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:]
Sent: Wednesday, December 15, 2010
11:20 AM
To:
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:]
Sent: Wednesday, December 15, 2010 9:57
AM
To:
Cc: ;
;
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,
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 <>
<mailto:>
To:
Cc: ;
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,
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 <>
<mailto:>
To: ;
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,
<>
wrote:
From:
<>
Subject: Re: [soa-rm-ra] Strawman of
outstanding issues
To: ,
,
,
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 <>
To: BorisLublinsky <>;
<>;
Peter F Brown at work <>
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 <
<http://us.mc556.mail.yahoo.com/mc/[email protected]>
> wrote:
From:
Peter F Brown at work <
<http://us.mc556.mail.yahoo.com/mc/[email protected]>
>
Subject: RE: [soa-rm-ra] Strawman of
outstanding issues
To: "Lublinsky, Boris" <
<http://us.mc556.mail.yahoo.com/mc/[email protected]>
>, "
<http://us.mc556.mail.yahoo.com/mc/[email protected]>
" <
<http://us.mc556.mail.yahoo.com/mc/[email protected]>
>
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:
<http://us.mc556.mail.yahoo.com/mc/[email protected]>
;
<http://us.mc556.mail.yahoo.com/mc/[email protected]>
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:
<http://us.mc556.mail.yahoo.com/mc/[email protected]&>
]
> Sent: Tuesday, December 07, 2010 8:09 PM
> To:
<http://us.mc556.mail.yahoo.com/mc/[email protected]>
> 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:[email protected]
<http://us.mc556.mail.yahoo.com/mc/[email protected]>
]
> 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.
