[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]