[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] NEWclass ISSUE: Java CI should have corresponding changesin JAVA-125 - [JAVA-153]
David Booz wrote:
> 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.
>
I'm not convinced that we could avoid making the first two of your changes.
Section 2.2 describes the semantics of a "Java service contract defined
by an interface or implementation class". This could be taken as having
broader scope than what appears in the introspected componentType for
implementation.java.
Another approach would be to reword this section to clarify that its
scope is restricted to services introspected from the Java implementation
class. Unfortunately, I'm having trouble coming up with suitable words
that are not open to ambiguity or misinterpretation.
> Also, JAVA-125 remains valid as specified and needs no changes either.
>
+1
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 10:07:23 AM---I
> thought of another possible use case. Some standard may havSimon 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
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]