Michael, Ken, All,
I do appreciate the thought Michael has invested in this area and I
completely agree that ESB is problematic, especially since it
appears to be solution in search of a problem, and has since become
a problem in its own right. However, that doesn't convince me that
we should consider the subject of Mediator open to change.
Cheers,
Rex
On 12/15/10 6:13 PM, Ken Laskey wrote:
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.
