[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]
Dave,
OK, here's my best attempt at clarifying the scope of section 2.2.
I have borrowed the opening words from section 2.3.
1. Replace the opening words of section 2.2:
A Java service contract defined by an interface or implementation
class....
by the following:
A Java service contract offered by a Java implementation class and
defined by a interface or implementation class....
2. In the second paragraph, change the opening words:
Unless annotated with a @Remotable annotation, a service defined by
a Java interface or a Java implementation class is inferred....
to the following:
Unless annotated with a @Remotable annotation, a service offered by
a Java implementation class and defined by a Java interface or a
Java implementation class is inferred....
Simon
David Booz wrote:
>
> 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 <oasis@cjnash.com> wrote on 04/23/2009 07:07:09 AM:
>
> > [image removed]
> >
> > Re: [sca-j] NEWclass ISSUE: Java CI should have corresponding
> > changes in JAVA-125 - [JAVA-153]
> >
> > Simon Nash
> >
> > to:
> >
> > sca-j
> >
> > 04/23/2009 07:07 AM
> >
> > 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.
>
> I take that to be the context of the entire spec. I guess I'd need to see
> some wording proposals (even if they aren't ideal). At this point I'm
> still inclined to CNA this issue.
>
> >
> > > 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
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]