-----Original Message-----
From:
To:
Sent: Fri, Dec 17, 2010 7:40 pm
Subject: Re: [soa-rm-ra] Re: Further Note on Mediator
OK, this is my fault that this issue has not been in the focus since 7-28-2010.
Rex, a verb 'mediating' and a term 'Mediator' is not the same thing. Many thing that are positioned between others mediate not being Mediators. For example, I see an architectural problem in your statement: " a critically important way mediating visibility and providing a mechanism for service descriptions to specify their requirements in emergency alerting". Registry/repository mediates in declaration, i.e. visibility, of the services but it is not a Mediator in sense of emergency alerting. By definition of registry/repository, it is a passive storage of data: if data is alerting in semantics, the registry/repository does not and should not care about it but another entity that might monitor the registry/repository, should find this alerting data and react. In this case the registry/repository is used in the process of emergency alerting but the Mediator is that external entity that finds the alert and reacts with the Mediator outcome - the alert notifications. Only in this case there is a lean and clear architectural functional separation of concerns work.
- Michael
-----Original Message-----
From: Rex Brooks <>
To: Bashioum, Christopher D <>
Cc: <>; <>; <>; <>; <>
Sent: Fri, Dec 17, 2010 4:27 pm
Subject: Re: [soa-rm-ra] Re: Further Note on Mediator
If this is the consensus, fair enough. As long as
registry/repository is not excluded, I'm okay. However, I have
existing work which uses this in a critically important way
mediating visibility and providing a mechanism for service
descriptions to specify their requirements in emergency alerting, so
I would appreciate it if we don't specifically exclude it. Otherwise
we may have a problem because this was not brought up to us
previously, and did not change from 7-28-2010. The amended
definition does not exclude it.
Cheers,
Rex
On 12/16/10 12:41 PM, Bashioum, Christopher D wrote:
For what its worth:Â Peter and I both also had
problems with registry/repository being a mediator. We
have re-worded, and taken reg/rep out.Â
Current wording is along the lines of mediator
facilitates discovering, offering, or using a service in
some way – can take many forms, and can itself make use of
other services in performing its job.Â
This is not the actual wording – Peter and I
are still going through internal discussion on a draft of
section 3 that we want to get to the rest of the TC
hopefully over the weekend.Â
From:
[mailto:]
Sent: Thursday, December 16, 2010 3:11 PM
To: ;
Cc: ;
Subject: Re: [soa-rm-ra] Re: Further Note on
Mediator
I
may be mistaken but this discussion started not because of
the definition of Service
Mediator in Section 3 but because service
registry/repository was recognised as service mediator. As
I understand, Boris and me and, probably Jim believe
that service registry/repository is not and may not be a
service mediator. If the definition of Service Mediator in Section 3
allows "service registry/repository = service mediator",
then this definition is incorrect. Are we going to go
'live' with such definition is another question.
- Michael
-----Original
Message-----
From: Rex Brooks <>
To: Lublinsky, Boris <>
Cc: James Odell <>;
<>
Sent: Thu, Dec 16, 2010 4:46 pm
Subject: 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:
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: rg/workgroup/portal/my_workgroups.php" target="_blank"
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.
