[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] ISSUE 3 - Local services expose implementation classes as their type
|
inline... -----Original Message----- I think we haven't completely dealt with this issue of
local interfaces. In the context of this proposal, I have to raise the
question of why there is no corresponding assembly model change. I don’t believe a change to the assembly model is needed. The
@Local annotation does not actually change the semantics of an interface. Merely
_not_ having an @Remotable also
means that the interface is local. However, by using @Local, you are
causing classes that implement that interface to have a <service>
declaration generated for it, where it wouldn’t have had a service
declared if there hadn’t been a @Local annotation. It also plays a
documentation role – making it clearer that the interface is purposefully
using local semantics (the @Remotable annotation wasn’t just forgotten). What does the generated componentType look like when used with @Local
interfaces? A service declaration for each implemented interface that had been
marked @Local, pointing to that interface for its type. Is it legal to specify a <sca:binding/> on the
<sca:service/> that is derived from implementing an @Local interface? The main reason I would think that the answer is “no”, is
that I don’t think it makes sense for local communication by-reference
calls to go through a binding. Can you think of a case where that would
be useful? If not, how do you know it's local? Because of the @Local annotation on the
interface that is referenced. (Although, perhaps I didn’t understand your
question.) This is certainly a problem in the existing spec, so
maybe this is a new issue, we can discuss on the call. Michael Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world
hunger" e-mail:booz@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"Michael
Rowley"
<mrowley@bea.com>
To
10/18/2007 02:48
"Michael Rowley" <mrowley@bea.com>,
PM
<sca-j@lists.oasis-open.org>
cc
Subject
RE: [sca-j] ISSUE 3 - Local
services expose implementation
classes as their type
PROPOSAL: Introduce a new interface annotation called
@Local. If a component implementation implements an interface that has been
marked as @Local, then the component type will include a service whose type
is that (non-remotable) interface. In this way, the
@Local annotation is similar to the @Remotable annotation, but without implying
remote-call semantics. The rules for generating services for a class that
does not include the @Service annotation are the following: 1) If the class implements interfaces, generate
services for each implemented interface that has been marked as either
@Remotable or @Local, where the type of the service is that interface.
Any implemented interfaces that have not been marked as either
@Remotable or @Local do not have services generated for them. 2) If none of the interfaces implemented by the class
has been marked as @Remotable or @Local, then generate a service for each
implemented interface that is not a “marker interface”
(i.e. an interface with no methods, like Serializable). 3) If the class implements no interfaces, then it
offers a single service whose type is that class. Michael
From: Barack, Ron [mailto:ron.barack@sap.com]
Sent: Thursday, October 04, 2007 5:27 AM.
To: sca-j@lists.oasis-open.org Subject:
[sca-j] ISSUE LOGGED: JAVA-3: Local services expose
implementation classes as their type
http://www.osoa.org/jira/browse/JAVA-3
Von:: Michael Rowley [mailto:mrowley@bea.com]
Gesendet: Mittwoch, 26. September 2007 00:22.
An: sca-j@lists.oasis-open.org
Betreff: [sca-j] NEW ISSUE: Local services expose
implementation classes as their type
TARGET: Java Common Annotations and APIs specification
Java Component Implementation Specification
Section titled: “Local and Remotable Services”
DESCRIPTION:
Currently, this section states the following:
If an implementation class has implemented interfaces that
are not decorated with an @Remotable annotation, the class
is considered to implement a single local service whose type
is defined by the class.
This is unfortunate, since the extremely common pattern of:
class FooImpl implements Foo {}
Will result in a component that offers a service whose type is
FooImpl (assuming that Foo hasn’t been marked as @Remotable).
It should be possible for this pattern to result in a service
whose type is the Foo interface.’
PROPOSAL:
Introduce a new interface annotation called @Local. If a
component implementation implements an interface that has been
marked as @Local, then the component type will include a
service whose type is that interface. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]