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:
4D065859.9050104@ncoic.org" type="cite">
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, mpoulin@usa.com
wrote:
8CD65F260583627-1F9C-188D1@web-mmc-m05.sysops.aol.com"
type="cite">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 <rexb@starbourne.com>
To: mpoulin@usa.com
Cc: danny_thornton2@yahoo.com;
soa-rm-ra@lists.oasis-open.org
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, mpoulin@usa.com
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 <danny_thornton2@yahoo.com>
To: soa-rm-ra@lists.oasis-open.org;
mpoulin@usa.com
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.
From: mpoulin@usa.com
<mpoulin@usa.com>
Subject: Re: [soa-rm-ra] Strawman of
outstanding issues
To: danny_thornton2@yahoo.com,
boris.lublinsky@navteq.com,
soa-rm-ra@lists.oasis-open.org,
peter@peterfbrown.com
Date: Wednesday, December 8, 2010,
1:15 PM
Danny,
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 < danny_thornton2@yahoo.com>
To: BorisLublinsky < boris.lublinsky@navteq.com>;
soa-rm-ra@lists.oasis-open.org
< soa-rm-ra@lists.oasis-open.org>;
Peter F Brown at work < peter@peterfbrown.com>
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 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.
From: Peter F
Brown at work
<peter@peterfbrown.com>
Subject: RE:
[soa-rm-ra]
Strawman of
outstanding
issues
To: "Lublinsky,
Boris" <boris.lublinsky@navteq.com>,
"soa-rm-ra@lists.oasis-open.org"
<soa-rm-ra@lists.oasis-open.org>
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
@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:
peter@peterfbrown.com;
soa-rm-ra@lists.oasis-open.org
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:peter@peterfbrown.com]
> Sent:
Tuesday,
December 07,
2010 8:09 PM
> To: soa-rm-ra@lists.oasis-open.org
> 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: image001.png@01CB96AC.EA7AD190]
>
Transforming
our
Relationships
with
Information
Technologies
> www.peterfbrown.com
>
@pensivepeter< "
target=_blank
rel=nofollowhttp://twitter.com/#!/@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
|
|
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
|