Re: [soa-rm-ra] Re: Further Note on Mediator
I decided to reply to the current last message in this thread in my
inbox and be done with it for a while.
I believe that while these are interesting discussions, I don't
think we ever opened the topic to any revisions. If I'm wrong,
please let me know.
However, regardless of that, these discussions go into more depth of
detail and split hairs over definitions that would entail exactly
the kind of further changes in related material in order for our
document to be consistent, that would in effect paralyze us, and,
therefore, go beyond merely being out of scope for a foundational
work, but also entail an exhaustive search through the document to
ensure consistency, and would only open further terms for
redefinition in an endless cycle.
At the most, I would be willing to include an orchestration
controller as another example of a Service Mediator, which is
defined:
A service mediator is participant that facilitates the offering or
use of services in some way.
I would not accept redefining service mediator to restrict it to
exchange of messages for the mediation of operations of some
service.
Cheers,
Rex
On 12/16/10 4:27 AM, Ken Laskey wrote:
A mediator takes an identified disconnect as
input and returns the result of bridging the disconnect as
the output, where the explicit idea of the disconnect is in
the mind of the consumer and not necessarily part of the
processing of the bridge. We may be tripping over words
but “transmitting connections†doesn’t capture this.
Ken
From:
[mailto:]
Sent: Thursday, December 16, 2010 7:16 AM
To: Laskey, Ken; ;
;
Subject: Re: [soa-rm-ra] Re: Further Note on
Mediator
The statement:
capability
of resolving disconnects
has a very fragile boundary with "assisting in resolving disconnects", like
registry/repository does while it does not mediate, it
does not transmit the connections. Why we cannot directly
say - Mediator must transmit connections within service
interactions (everything else is not a Mediator)?
-
Michael
P.S.
Did I really scared you, Ken?
-----Original
Message-----
From: Ken Laskey <>
To: 'Lublinsky, Boris'
<>; ;
;
Sent: Thu, Dec 16, 2010 12:08 pm
Subject: RE: [soa-rm-ra] Re: Further Note on Mediator
Can we say that a mediator
provides the capability of resolving disconnects,
where the disconnects are typically generic in
nature and the mediator can be applied against a
nonspecific set of instances where such
disconnects occur. Some mediators may deal with
disconnects in low level IT, i.e. part of the IT
business process and not visible to the typical
consumer of the process. Some mediators may be
higher level and identifiable as part of a
business process. Semantic/data model translation
would be an example of the latter. In addition,
what constitutes this “higher level†mediation
depends on the context of the consumer and where
they sit in the overall process. For someone
whose business is the lower level IT, it would be
indefensible to tell them that elements of their
process cannot be considered under the label of
mediation.
Michael’s horror stories have
more to do with bad design choices than the
concept of mediators, per se. If your motivation
for handing off problems to mediation pixie dust
is so you can hide your head in the sand and
pretend they don’t exist, then you are likely to
be burned at several levels, the least of which is
not properly defining mediation.
Ken
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S
H305 phone: 703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
McLean VA 22102-7508
From: Lublinsky, Boris [mailto:]
Sent: Thursday, December 16, 2010 6:24
AM
To: ;
Laskey, Ken; ;
Subject: RE: [soa-rm-ra] Re: Further
Note on Mediator
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:
[mailto:]
Sent: Thursday, December 16, 2010 4:31 AM
To: ;
;
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 <>
To: ;
;
Sent: Thu, Dec 16, 2010 2:13 am
Subject: RE: [soa-rm-ra] Re: Further Note on
Mediator
Michael,
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.
Ken
---------------------------------------------------------------------------
Dr. Kenneth
Laskey
MITRE
Corporation, M/S H305
phone: 703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
McLean VA
22102-7508
From:
[mailto:]
Sent: Wednesday, December 15,
2010 8:02 PM
To: ;
Subject: Re: [soa-rm-ra] Re:
Further Note on Mediator
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.
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.
=