[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 changes inJAVA-125 - [JAVA-153]
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]