Next in thread →
Next in month →
Re: [sca-j] Potential issues
From JSR 181 (JSR_181_web_services_metadata_2_0_spec.pdf)
section 4.1.1: Marks a Java class as implementing a WebService, or
a Java interface as defining a WebService interface.
In general, in SCA the name of a service
in a componentType is the name of of the implementation object that defines
the operations of the object (the portType in WSDL) so if a interface indicates
via a @WebService annotation that its portType is named foo, the name of
a service with the interface should also be named foo.
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:
From:
Shih-Chang Chen <>
To:
Bryan Aupperle/Raleigh/IBM@IBMUS
Cc:
Date:
09/02/2010 10:08 AM
Subject:
Re: [sca-j] Potential issues
According to JSR-181 where the @WebService is defined,
the value
of @WebService.name is mapped to wsdl:portType name and
@WebService.serviceName is mapped to wsdl:service name. The
@WebService.serviceName is however only allowed on implmentation
or class; it is not allowed on interface.
It seems to me the specs overload the meaing of @WebService.name
that "If used to define a service, sets service name", is this
the cause of the problem?
Thanks,
-chen
> While working on the new test cases for Issue 209, two potential issues
> arose.
>
> 1) Interaction between @Service and @WebService
> Consider the following...
>
> @Service(ServiceWithName.class)
> public class serviceWithNameImpl implements ServiceWithName {
> ...
> }
>
> and
>
> @WebService(name="AnnotationName")
> @Remotable
> public interface ServiceWithName {
> ...
> }
>
> The @Service annotation would imply that the service name of a component
> using serviceWithNameImpl as an implementation would be ServiceWithName
> but @WebService annotation requires the service name to be
> AnnotationName. Which takes precedence? Or should the
conflict be
> raised as an error?
>
> 2) We may have misinterpreted the impacts of @WebFault. The
current
> text in both the CAA and JCI specs indicates that the name attribute
of
> a @WebFault annotation impacts the name of the fault in the interface.
> Some experimentation suggests that this is not the case.
> The combination of :
>
> @WebService
> public class Service1WithFaultWFImpl implements Service1WithFaultWF
{
>
> public String operation1(String input)
throws BusinessFault3 {
> ...
> }
> }
>
> @WebService
> public interface Service1WithFaultWF {
>
> public String operation1 ( String input
) throws BusinessFault3;
> }
>
> @WebFault(name="BusinessFault")
> public class BusinessFault3 extends Exception {
> ...
> }
>
> and
>
> public class BusinessFault3Bean {
> private String data;
>
> public String getData() {
> return data;
> }
>
> public void setData(String faultData)
{
> data = "faultData;
> }
> }
>
> result in a WSDL file of
>
> <?xml version="1.0" encoding="UTF-8"?><!--
Generated by JAX-WS RI at
> http://jax-ws.dev.java.net
<http://jax-ws.dev.java.net/>.
RI's version
> is JAX-WS RI 2.1.1 in JDK 6. --><definitions
> name="Service1WithFaultWFImplService" targetNamespace="http://test/"
> xmlns="http://schemas.xmlsoap.org/wsdl/"
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> xmlns:tns="http://test/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <types>
> <xsd:schema>
> <xsd:import namespace="http://test/"
> schemaLocation="Service1WithFaultWFImplService_schema1.xsd"/>
> </xsd:schema>
> </types>
> <message name="operation1">
> <part element="tns:operation1" name="parameters"/>
> </message>
> <message name="operation1Response">
> <part element="tns:operation1Response"
name="parameters"/>
> </message>
> <message name="BusinessFault3">
> <part element="tns:BusinessFault" name="fault"/>
> </message>
> <portType name="Service1WithFaultWFImpl">
> <operation name="operation1">
> <input message="tns:operation1"/>
> <output message="tns:operation1Response"/>
> <fault message="tns:BusinessFault3"
name="BusinessFault3"/>
> </operation>
> </portType>
> <binding name="Service1WithFaultWFImplPortBinding"
> type="tns:Service1WithFaultWFImpl">
> ...
> </binding>
> <service name="Service1WithFaultWFImplService">
> ...
> </service>
> </definitions>
>
> with
>
> <?xml version="1.0" encoding="UTF-8"?><xs:schema
> targetNamespace="http://test/"
version="1.0" xmlns:tns="http://test/"
> xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
> <xs:element name="BusinessFault" nillable="true"
> type="tns:businessFault3Bean"/>
>
> <xs:element name="operation1" type="tns:operation1"/>
>
> <xs:element name="operation1Response" type="tns:operation1Response"/>
>
> <xs:complexType name="operation1">
> ...
> </xs:complexType>
>
> <xs:complexType name="operation1Response">
> ...
> </xs:complexType>
>
> <xs:complexType name="businessFault3Bean">
> <xs:sequence>
> <xs:element minOccurs="0" name="data"
type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>
>
>
> Note that in the operation, the name of the fault s BusinessFault3,
not
> BusinessFault. The name attribute of the @WebFault annotation
only
> impacts the local name of the global element. A closer reading
of the
> JAX-WS spec is consistent with this behavior. I think we may
need to
> change the @WebFault content of table 11.2 of the CAA spec to remove
the
> impact of the name attribute on the interface, removing normative
> statement JCA100027, and remove section 8.2.6 of the JCI spec
>
> 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:
Next in thread →
Next in month →