Title: Re: [soa-rm-ra] Re: Further Note on Mediator
We define Service Mediator in Section 3. We haven't changed and I
don't recall reaching consensus that it should be opened to change
except insofar as Peter and Chris recommend it, and then we should
discuss it.
Opening up all these questions begs the question of whether we want
to finish this work. We've been over much of this but we never set
out to answer such questions which I think go into greater depth
than a foundational work should undertake. If we do this we'll be at
it another several years.
Cheers,
Rex
On 12/16/10 12:41 AM, Lublinsky, Boris wrote:
"
type="cite">
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:]
Sent: Wednesday, December 15, 2010 4:46 PM
To:
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.
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.
