I suppose an example would help explain
what I meant by “two services with the same interface” (I should
have at least said “two service on the same component that both provide
the same interface”).
interface Ping
{
void sendPing();
}
<componentType name=”FooType”>
<service name=”X”
type=”Ping”/>
<service name=”Y”
type=”Ping”/>
</componentType>
<composite>
<component name=”Foo”>
<implemention.abstract type=”FooType”/>
</component>
<component name=”FooClient1”>
<implementation.something/>
<reference name=”myX”
target=”Foo/X”/>
</component>
<component name=”FooClient2”>
<implementation.something/>
<reference name=”myY”
target=”Foo/Y”/>
</component>
</composite>
Notice that the component named “Foo”
offers two services (“X” and “Y”), both have the same
interface. I think presents a problem if you are going to map these to UML’s
concept of a “provided interface”. (BTW, this isn’t relevant
to components written in Java, since Java can’t do this, but BPEL can).
Foo’s two different service can be
addressed seperately. FooClient1 is wired to Foo/X, while FooClient2 is wired
to Foo/Y.
Michael
From: Duane
Nickull [mailto:dnickull@adobe.com]
Sent: Friday, October 05, 2007
11:49 AM
To: Michael Rowley;
sca-assembly@lists.oasis-open.org
Subject: Re: [sca-assembly] ISSUE
2: Use of UML 2.0
Michael:
I agree that UML is not for everyone and would strongly encourage its use only
where the ambiguity resulting from using a simpler convention may lead to
circumvention of the specs. However..it is a normative convention and
does provide a level of specification that these specs require in some cases.
Your comments about the semantics confused me (yes – I know the S word
can be a big rat hole).
On 10/5/07 6:42 AM, "Michael Rowley" <mrowley@bea.com> wrote:
“two services with the
same interface, or two components implemented using the same class”
Wouldn’t two services using the same interface be the same service with
two different functions (overloading capabilities)? Why would that not be
express able in UML CVD? Maybe I am missing something but if you are
simply referring to a service interface whereby it can accept tokens A, B and C
as its input data model, does function X and returns Z (but optionally you can
send B, C and D, it does function Y and sends you return value Y) this is akin
the the concept of overloading a class interface and is (IMO) a somewhat common
variation of a service interaction using the request-response behavior model
(not that using other behavior models like subscribe-push should really affect
this).
I guess it depends upon what is considered to make a service unique (endpoint
vs. operations). Apologies if I have missed the point.
The second part you talked about is also something we should be able to express
in UML.
Duane
--
**********************************************************************
"Speaking only for myself"
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
MAX 2007 - http://technoracle.blogspot.com/2007/07/adobe-max-2007.html
**********************************************************************