atom feed15 messages in org.oasis-open.lists.sca-jRE: [sca-j] ISSUE 3 - Local services ...
FromSent OnAttachments
Michael RowleySep 25, 2007 3:21 pm 
Barack, RonOct 4, 2007 2:30 am 
Michael RowleyOct 4, 2007 6:30 am 
Michael RowleyOct 18, 2007 11:48 am 
David BoozNov 1, 2007 9:53 am 
Michael RowleyNov 5, 2007 8:53 am 
Simon NashNov 5, 2007 10:46 am 
Reza ShafiiNov 5, 2007 10:54 am 
Simon NashNov 5, 2007 1:10 pm 
David BoozNov 7, 2007 12:59 pm 
Blohm, HenningNov 8, 2007 5:55 am 
Michael RowleyNov 14, 2007 1:34 am 
Michael RowleyNov 14, 2007 1:34 am 
David BoozNov 14, 2007 7:41 am 
Simon NashNov 14, 2007 2:46 pm 
Subject:RE: [sca-j] ISSUE 3 - Local services expose implementation classes as their type
From:Michael Rowley (mrow@bea.com)
Date:Nov 5, 2007 8:53:40 am
List:org.oasis-open.lists.sca-j

inline...

-----Original Message----- From: David Booz [mailto:bo@us.ibm.com] Sent: Thursday, November 01, 2007 12:55 PM To: sca@lists.oasis-open.org Subject: RE: [sca-j] ISSUE 3 - Local services expose implementation classes as their type

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"

Poughkeepsie, NY (845)-435-6093 or 8-295-6093

e-mail:bo@us.ibm.com

http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome

"Michael Rowley"

<mrow@bea.com>

To

10/18/2007 02:48 "Michael Rowley" <mrow@bea.com>,

PM <sca@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.@sap.com]

Sent: Thursday, October 04, 2007 5:27 AM.

To: sca@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:mrow@bea.com]

Gesendet: Mittwoch, 26. September 2007 00:22.

An: sca@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.