Re: [sca-j] NEWclass ISSUE: Java CI should have corresponding changes inJAVA-125 - [JAVA-153]

[David Booz <booz@us.ibm.com>]

Interesting use case. You're asserting remote-ability onto the interface but in a way that doesn't affect (but is "compatible" with) the componentType.

And getting right to the punch line, it means that JAVA-153 could be closed with no action. None of the three places I originally identified in JAVA-153 would need to be changed to enable this use case, and those changes would make no sense in other use cases.

Also, JAVA-125 remains valid as specified and needs no changes either.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Simon Nash ---04/21/2009 10:07:23 AM---I thought of another possible use case. Some standard may have defined a Java interface that is sem

From:	Simon Nash <oasis@cjnash.com>
To:	sca-j@lists.oasis-open.org
Date:	04/21/2009 10:07 AM
Subject:	Re: [sca-j] NEWclass ISSUE: Java CI should have corresponding changes in JAVA-125 - [JAVA-153]

---

I thought of another possible use case.  Some standard may have
defined a Java interface that is semantically remotable but is
not marked with the @Remotable annotation.  Let's say this
interface is org.foo.Bar.

A vendor would like to create an SCA component with a remotable
service that implements the org.foo.Bar interface.  It can do
this by extending the org.foo.Bar interface with a stub interface
and adding an @Remotable annotation on the stub interface.
Here's some example code to do this:

package com.somevendor;

@Remotable
public interface BarService extends org.foo.Bar {
}

public class BarRemotableImpl implements BarService {
     ....
}

The componentType will have a service BarService whose
interface is com.somevendor.BarService.  In the component
configuration, the service interface could be configured as
   <service name="BarService">
       <interface.java interface="org.foo.Bar" remotable="true"/>
   </service>

This avoids the need to expose the stub interface
com.somevendor.BarService to clients of the service.

Unfortunately it will be necessary for SCA clients to create a
similar stub interface on their end to create references that
can be wired to the service.  It is possible that non-SCA
clients could use the org.foo.Bar interface directly.

   Simon

Simon Nash wrote:
> David Booz wrote:
>> This calls into question the resolution of issue 125. It doesn't seem 
>> possible for a CI to support the use of @remotable on interface.java 
>> unless the CI support componentType side files and the specification 
>> of @remotable appears in a componentType.
>>
>> Either that or we have to change the assembly rules and allow a 
>> component interface declaration to assert the remotable aspect onto a 
>> componentType, which doesn't seem desirable.
>>
>> For JCI, we could decide that interface.java/@remotable is just not 
>> supported but leave it there in the JCAA for other Java based CIs to 
>> use. Graham may have had some other use cases in mind which we should 
>> not arbitrarily remove.
>>
> We should leave it there.  It could be used in a contrainingType.
> 
>   Simon
> 
>>
>> Dave Booz
>> STSM, BPM and SCA Architecture
>> Co-Chair OASIS SCA-Policy TC and SCA-J TC
>> "Distributed objects first, then world hunger"
>> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
>> e-mail:booz@us.ibm.com
>>
>> Inactive hide details for Simon Nash ---04/21/2009 06:22:59 AM---Mike, 
>> The paragraph in question (in section 2.3) says which seSimon Nash 
>> ---04/21/2009 06:22:59 AM---Mike, The paragraph in question (in 
>> section 2.3) says which services are
>>
>>
>> From:   
>> Simon Nash <oasis@cjnash.com>
>>
>> To:   
>> sca-j@lists.oasis-open.org
>>
>> Date:   
>> 04/21/2009 06:22 AM
>>
>> Subject:   
>> Re: [sca-j] NEW ISSUE: Java CI should have corresponding changes in 
>> JAVA-125 - [JAVA-153]
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Mike,
>> The paragraph in question (in section 2.3) says which services are
>> selected by the component type introspection algorithm in the absence
>> of @Service annotations.  This paragraph currently says that only
>> those interfaces with a @Remotable annotation would be selected.
>> The proposed change attempts to broaden this, and from your comments
>> here I believe you are agreeing that this broadening would not
>> be possible.
>>
>> Regarding your second point of using <interface.java> in a component
>> definition to affect the remotable state of the interface, we realised
>> on yesterday's call that this doesn't work because it violates the
>> compatibility relationship between component type and component.
>> If the introspected component type detects a service interface as
>> being local because it isn't annotated with @Remotable, the component
>> definition cannot specify a remotable interface because this would
>> violate the definition of compatibility in the Assembly spec.
>>
>> I think the only way round this would be to re-introduce a
>> .componentType side file for Java implementations so that the
>> component type's service interface could be marked as remotable
>> using the @remotable attribute on <interface.java>.
>>
>>   Simon
>>
>> Mike Edwards wrote:
>>  >
>>  > Simon,
>>  >
>>  > I don't read the new sections in the way that you do and I don't see a
>>  > problem.
>>  >
>>  > I agree that if a Java POJO implements an interface that is not marked
>>  > remotable and
>>  > does not mark that interface as being a Service, then it will not 
>> appear
>>  > in the component
>>  > type of the POJO as a service and so cannot be used as such - 
>> making the
>>  > question
>>  > of marking it remotable with <interface,java/> moot.
>>  >
>>  > However, Mark's suggested sections don't contradict this.  The section
>>  > on calculation
>>  > of component type remains unchanged.  Only once the service appears in
>>  > the component
>>  > type can the use of the attribute on <interface.java/> affect the
>>  > remotable state of the
>>  > interface....
>>  >
>>  >
>>  > Yours,  Mike.
>>  >
>>  > Strategist - Emerging Technologies, SCA & SDO.
>>  > Co Chair OASIS SCA Assembly TC.
>>  > IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
>>  > Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431   > Email:  
>> mike_edwards@uk.ibm.com
>>  >
>>  >
>>  > From: Simon Nash <oasis@cjnash.com>
>>  > To: sca-j@lists.oasis-open.org
>>  > Date: 20/04/2009 15:30
>>  > Subject: Re: [sca-j] NEW ISSUE: Java CI should have corresponding
>>  > changes in JAVA-125 - [JAVA-153]
>>  >
>>  >
>>  > 
>> ------------------------------------------------------------------------
>>  >
>>  >
>>  >
>>  > Mike,
>>  > My concern is not about local services but about remotable services.
>>  >
>>  > In the absence of @Service, the introspection algorithm identifies
>>  > interfaces implemented by the implementation class as being
>>  > SCA services if they carry a @Remotable annotation.  The proposed
>>  > change would extend this to include the case where the interface
>>  > doesn't carry a @Remotable annotation, but the <interface.java>
>>  > element in a component configuration carries a @remotable attribute.
>>  >
>>  > This can't work because the introspection algorithm for discovering
>>  > which services should be included in the componentType only has
>>  > access to the Java interfaces and not to any component configurations
>>  > that may configure these Java interfaces as being remotable SCA
>>  > services.  In order to do this, the @Service annotation would need
>>  > to be used.
>>  >
>>  >   Simon
>>  >
>>  > Mike Edwards wrote:
>>  >  >
>>  >  > Simon,
>>  >  >
>>  >  > I don't follow your point below.
>>  >  >
>>  >  > Mark's text seems to work just fine.  So you can't introspect a 
>> local
>>  >  > interface as a Service if it is not
>>  >  > used by a @Service annotation.  I agree - but that does not 
>> contradict
>>  >  > the statements made in Mark's
>>  >  > formulation.
>>  >  >
>>  >  > Yours,  Mike.
>>  >  >
>>  >  > Strategist - Emerging Technologies, SCA & SDO.
>>  >  > Co Chair OASIS SCA Assembly TC.
>>  >  > IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great 
>> Britain.
>>  >  > Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431   >  > 
>> Email:  mike_edwards@uk.ibm.com
>>  >  >
>>  >  >
>>  >  > From:                  Simon Nash <oasis@cjnash.com>
>>  >  > To:                  sca-j@lists.oasis-open.org
>>  >  > Date:                  20/04/2009 13:26
>>  >  > Subject:                  Re: [sca-j] NEW ISSUE: Java CI should 
>> have
>>  > corresponding
>>  >  > changes in JAVA-125 - [JAVA-153]
>>  >  >
>>  >  >
>>  >  > 
>> ------------------------------------------------------------------------
>>  >  >
>>  >  >
>>  >  >
>>  >  > Mark Combellack wrote:
>>  >  >  > Hi,
>>  >  >  >
>>  >  >  >   >  >  >
>>  >  >  > Raised as new issue 153. See 
>> http://www.osoa.org/jira/browse/JAVA-153
>>  >  >  >
>>  >  >  >   >  >  >
>>  >  >  > Thanks,
>>  >  >  >
>>  >  >  >   >  >  >
>>  >  >  > Mark
>>  >  >  >
>>  >  >  >   >  >  >
>>  >  >  > Mark Combellack| Software Developer| Avaya | Eastern Business 
>> Park
>>  > | St.
>>  >  >  > Mellons | Cardiff | CF3 5EA | Voice: +44 (0) 29 2081 7624 |
>>  >  >  > mcombellack@avaya.com <mailto:|mcombellack@avaya.com>
>>  >  >  >
>>  >  >  >
>>  > 
>> ------------------------------------------------------------------------
>>  >  >  >
>>  >  >  > *From:* David Booz [mailto:booz@us.ibm.com]
>>  >  >  > *Sent:* 26 March 2009 13:11
>>  >  >  > *To:* sca-j@lists.oasis-open.org
>>  >  >  > *Subject:* [sca-j] NEW ISSUE: Java CI should have corresponding
>>  > changes
>>  >  >  > in JAVA-125
>>  >  >  >
>>  >  >  >   >  >  >
>>  >  >  > TARGET: Java C&I WD05 [1]
>>  >  >  >
>>  >  >  > DESCRIPTION:
>>  >  >  > Issue 125 [2] should have had corresponding changes in Java 
>> C&I spec,
>>  >  >  > see Section 2.2.
>>  >  >  >
>>  >  >  > PROPOSAL:
>>  >  >  > Section 2.2 line 144-146, change to:
>>  >  >  > A Java service contract defined by an interface or 
>> implementation
>>  > class
>>  >  >  > uses the @Remotable annotation or @remotable on 
>> <interface.java/> to
>>  >  >  > declare that the service follows the semantics of remotable
>>  > services as
>>  >  >  > defined by the SCA Assembly Specification, otherwise it is 
>> inferred to
>>  >  >  > be a local service.
>>  >  >  >
>>  >  >  > Delete Line 156-158.
>>  >  >  >
>>  >  >  > Line 164-169, change to:
>>  >  >  > If the interfaces of the SCA services are not specified with the
>>  >  >  > @Service annotation on the implementation class, it is assumed
>>  > that all
>>  >  >  > implemented interfaces that are remotable, as defined in
>>  > [JAVACAA], are
>>  >  >  > the service interfaces provided by the component. If an 
>> implementation
>>  >  >  > class has only implemented interfaces that are not remotable, 
>> the
>>  > class
>>  >  >  > is considered to implement a single */local/* service whose 
>> type is
>>  >  >  > defined by the class (note that local services can be typed 
>> using
>>  > either
>>  >  >  > Java interfaces or classes).
>>  >  >  >
>>  >  > This doesn't work because the list of available services is part of
>>  >  > the componentType and is determined by introspection.  If one of 
>> the
>>  >  > interfaces implemented doesn't use @Remotable but is configured in
>>  >  > the component definition using the @remotable attribute, it 
>> can't be
>>  >  > introspected as a service interface for the componentType.
>>  >  >
>>  >  >   Simon
>>  >  >  >
>>  >  >  > [1]
>>  >  >  >
>>  >  >
>>  > 
>> http://www.oasis-open.org/committees/download.php/31836/sca-javaci-1.1-spec-wd05.pdf 
>>
>>  >  >  > [2] http://www.osoa.org/jira/browse/JAVA-125
>>  >  >  >
>>  >  >  >
>>  >  >  >
>>  >  >  > Dave Booz
>>  >  >  > STSM, BPM and SCA Architecture
>>  >  >  > Co-Chair OASIS SCA-Policy TC and SCA-J TC
>>  >  >  > "Distributed objects first, then world hunger"
>>  >  >  > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
>>  >  >  > e-mail:booz@us.ibm.com
>>  >  >  >
>>  >  >
>>  >  >
>>  >  >
>>  >  > 
>> ---------------------------------------------------------------------
>>  >  > 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
>>  >  >
>>  >  >
>>  >  >
>>  >  >
>>  >  >
>>  >  >
>>  >  > 
>> ------------------------------------------------------------------------
>>  >  >
>>  >  > /
>>  >  > /
>>  >  >
>>  >  > /Unless stated otherwise above:
>>  >  > IBM United Kingdom Limited - Registered in England and Wales 
>> with number
>>  >  > 741598.
>>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>>  > PO6 3AU/
>>  >  >
>>  >  >
>>  >  >
>>  >  >
>>  >  >
>>  >  >
>>  >
>>  >
>>  >
>>  > ---------------------------------------------------------------------
>>  > 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
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > 
>> ------------------------------------------------------------------------
>>  >
>>  > /
>>  > /
>>  >
>>  > /Unless stated otherwise above:
>>  > IBM United Kingdom Limited - Registered in England and Wales with 
>> number
>>  > 741598.
>>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
>> PO6 3AU/
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 



---------------------------------------------------------------------
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