[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] ISSUE 212: @Service vs. @WebService name conflicts
Thinking more on this -- We treat @Webservice as a shorthand for @Service when no @Service is present. The case that we are considering is where there is an @Webservice annotation on the interface or a superclass and a @Service annotation on the subclass. The way I think about it is: if the developer used the @Service annotation when there is a @Webservice annotation already present on the superclass it is because he wanted to add to or replace what is already specified by the @Webservice annotation -- either because the superclass/interface cannot be changed (no permission) OR it would be inappropriate to change (because there are other subclasses/implementation of that superclass/interface or the same class may be used in SCA and non-SCA environment). So if there is a name clash between the @Service and @Webservice, then @Service wins -- the dev intend here is to override (why else would they use the annotation). If there is no name clash then it adds additional SCA service(s) (why else would they use the annotation). This is amalgamation (perhaps with some mercury toxins ;-)) of Bryan's option 2 and 3 (since @Service can specify a list of name-value pairs). Treating it as an error (Bryan's option 1) means there is no way to override/add any more services. Comments? -Anish -- On 10/4/2010 12:23 PM, David Booz wrote: > I think I need to clarify as I look at this a little differently. > > An implementation can only define one service by any given name. If the > @Webservice and @Service annotations define a service of the same name, > then I'd assert that: > 1) If the interface and policy intents are the same for each service, then > there is only one service defined, and there is no error. > 2) If the interface and/or policy intents are different, then there is an > error because the same service is trying to be defined twice, OR > 3) If the interface and/or policy intents are different, then the @Service > annotation wins, there is one service defined. > > If the @Webservice and @Service annotations define services which have > different names (but potentially the same interface and policy intents), > then either: > A) There are two services defined, OR > B) @Webservice and @Servce can't both be used to define services, so only > the @Service defined service is used. > > I think this comes down to the prominence of @Webservice annotations for > defining services. > If we think that @Service is primary, and @Webservice is only considered in > the absence of any @Service annotation, then we'd pick behaviors 1,3,B. > If we think that @Webservice is a more narrow synonym for @Service, then > we'd pick behaviors 1,2,A. > > Behaviors 1,3,B correspond to the third grouping in Bryan's email. > Behaviors 1,2,A correspond to parts of the other two groupings because of > the optimized case in behavior 1. Perhaps someone will make the case that > behavior 1 as defined isn't sufficient to determine equivalence of intent > on the part of the developer to converge the definition of a service across > the two intents. > > 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 > > > |------------> > | From: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Bryan Aupperle/Raleigh/IBM@IBMUS | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | To: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |sca-j@lists.oasis-open.org | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Date: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |10/04/2010 01:57 PM | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Subject: | > |------------> > >--------------------------------------------------------------------------------------------------------------------------------------------------| > |Re: [sca-j] ISSUE 212: @Service vs. @WebService name conflicts | > >--------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > > After today's call we have three possible approaches to resolving this > issue: Treating a name conflict as an error, having different names define > multiple services or name from @Service overrides name from @WebService. > > Here is a starting list of the advantages and disadvantages of each... > > Treating a name conflict as an error: > Advantages > No surprise services defined > No need to try and infer developer's intentions > Disadvantages > Forces a developer to make source changes to fix error > Removes developer's control over the SCA service name (i.e. is forced > to use name from @WebService) > > Different names define multiple services: > Advantages > Allows for different services with different sets of intents > No need to try and infer developer's intentions > Generalizes to any service name mismatch scenarios > Disadvantages > Potential developer surprise at additional service(s) being created > > Name from @Service overrides name from @WebService: > Advantages > Keeps developer's control over the SCA service name > Idea is that @Service was added for a reason > Disadvantages > Does not address conflicting @WebService names (@WebService on both > interface and implementation class) > Potential confusion if a client is using a WSDL document derived, > using JAX-WS tools, from the @WebService annotation (i.e. WSDL portName and > SCA service name would not match) > > Bryan Aupperle, Ph.D. > STSM, WebSphere Enterprise Platform Software Solution Architect > WW Center of Excellence for Enterprise Systems& Banking Center of > Excellence Application Integration Architect > > Research Triangle Park, NC > +1 919-254-7508 (T/L 444-7508) > Internet Address: aupperle@us.ibm.com > > > From: Bryan Aupperle/Raleigh/IBM@IBMUS > > To: sca-j@lists.oasis-open.org > > Date: 09/24/2010 09:26 AM > > Subject: [sca-j] ISSUE 212: @Service vs. @WebService name conflicts > > > > > > > > I have uploaded a proposal for Issue 212 base on the discussion in Monday's > call [1]. It includes an additional normative statement in the CAA spec, > with a corresponding Test Assertion and TestCase and comments in the CI > spec including a reference to the CAA spec. The bulk of the test artifacts > for the test case are available [2]. The updated version of > tuscany-oasis-sca-tests-errors.properties is not ready yet. Tuscany needs > to add a test for this mismatch and until that is done I do not know what > the error message will be. > > [1] > https://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/39538/Issue%20212.zip > > [2] > http://tools.oasis-open.org/version-control/browse/wsvn/sca-j/TestCases/?rev=199&sc=1 > > > Bryan Aupperle, Ph.D. > STSM, WebSphere Enterprise Platform Software Solution Architect > WW Center of Excellence for Enterprise Systems& Banking Center of > Excellence Application Integration Architect > > Research Triangle Park, NC > +1 919-254-7508 (T/L 444-7508) > Internet Address: aupperle@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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]