RE: The Attributes and the UN-wrapper style
If you have an attribute in the wrapper element definition, Axis should generate a document style service, not a wrapped style service. -Original Message- From: Jeff Greif [mailto:[EMAIL PROTECTED] Sent: Friday, September 10, 2004 10:09 PM To: [EMAIL PROTECTED] Subject: Re: The Attributes and the UN-wrapper style A speculation (I'm not an expert): If you have wrapper someatt=somevalue part1.../part1 part2.../part2 /wrapper being converted to a method call on the server: ServiceClass.someMethod(part1, part2) the attributes are lost. There is no way in wsdl to specify parts which correspond to attributes in wsdl. As for using attributes in the non-wrapped implementation, in the wsdl, you cannot tell whether a document style service will be implemented as the wrapped form or the someMethod(wrapper) form, so the client would not be able to tell whether the attributes would be lost in the server or not. The implementation should be able to change transparently between the two forms without affecting the abstract description or the client. Jeff - Original Message - From: Liu, Scott [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 10, 2004 4:31 PM Subject: The Attributes and the UN-wrapper style Hi, All, There has been discussion about the wrapper style and the attributes in the past. And Axis does not support wrapper element attributes since JAX-RPC spec says that the wrapper element should not have attributes. I have no problem with it. But I do like people to clarify the following questions. 1. I know that it might be against the spec to have attributes for the wrapper element. But it is such a simple change on Axis to support attributes (I made minor change on client code generated with Axis tool and it worked) I am wondering why the JAX-RPC insists that there is no attributes for the wrapper element (.NET supports the attributes anyway)? Does anyone know the story behind this? 2. I did not read the whole JAX-RPC spec and so what I said might be wrong. Correct me if it is the case. Since attributes are such a big part of xml schema and if I use the attributes to go with the UN-wrapped style does Axis support it? My test revealed that it did not with v1.1. Is there a patch or will it be supported in Axis 1.2 for un-wrapped style? Your explanation is highly appreciated, Thanks, Scott
RE: The Attributes and the UN-wrapper style
If you have an attribute in the wrapper element definition, Axis should generate a document style service, not a wrapped style service. -Original Message- From: Jeff Greif [mailto:[EMAIL PROTECTED] Sent: Friday, September 10, 2004 10:09 PM To: [EMAIL PROTECTED] Subject: Re: The Attributes and the UN-wrapper style A speculation (I'm not an expert): If you have wrapper someatt=somevalue part1.../part1 part2.../part2 /wrapper being converted to a method call on the server: ServiceClass.someMethod(part1, part2) the attributes are lost. There is no way in wsdl to specify parts which correspond to attributes in wsdl. As for using attributes in the non-wrapped implementation, in the wsdl, you cannot tell whether a document style service will be implemented as the wrapped form or the someMethod(wrapper) form, so the client would not be able to tell whether the attributes would be lost in the server or not. The implementation should be able to change transparently between the two forms without affecting the abstract description or the client. Jeff - Original Message - From: Liu, Scott [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 10, 2004 4:31 PM Subject: The Attributes and the UN-wrapper style Hi, All, There has been discussion about the wrapper style and the attributes in the past. And Axis does not support wrapper element attributes since JAX-RPC spec says that the wrapper element should not have attributes. I have no problem with it. But I do like people to clarify the following questions. 1. I know that it might be against the spec to have attributes for the wrapper element. But it is such a simple change on Axis to support attributes (I made minor change on client code generated with Axis tool and it worked) I am wondering why the JAX-RPC insists that there is no attributes for the wrapper element (.NET supports the attributes anyway)? Does anyone know the story behind this? 2. I did not read the whole JAX-RPC spec and so what I said might be wrong. Correct me if it is the case. Since attributes are such a big part of xml schema and if I use the attributes to go with the UN-wrapped style does Axis support it? My test revealed that it did not with v1.1. Is there a patch or will it be supported in Axis 1.2 for un-wrapped style? Your explanation is highly appreciated, Thanks, Scott
RE: The Attributes and the UN-wrapper style
The JAX-RPC spec prohibits use of attributes as content of the wrapper element, but it says nothing regarding attributes as content of the elements which are children of the wrapper element. Many other implementations support attributes as content of the child elements. So this is prohibited: element name=wrapper complexType sequence element name=foo type=string/ /sequence attribute name=bar type=string/ /complexType /element But this should be okay: element name=wrapper complexType sequence element name=foo type=string/ element name=bar type=tns:bar/ /sequence /complexType /element complexType name=bar sequence element name=bat type=string/ /sequence attribute name=baz type=string/ /complexType Unfortunately, the WS-I Basic Profile doesn't talk about wrapped versus document style, so there's no definitive source of enlightenment for the correct way to implement wrapped style. Axis document style supports interoperability with .NET wrapped style when using attributes, so I don't view this as a serious problem, although obviously lack of support for attributes in the wrapper element reduces the ease of use of Axis. Given that code generated by a wsdl2java tool is always dependent on the associated SOAP engine, I don't see a breach of JAX-RPC compliance in this small area as a particularly bad thing. I think more seamless interoperability with .NET is always desirable. But I suspect that others might feel differently. I also suggest that folks submit feedback to the JAX-RPC Expert Group and request support for attributes in wrapped style in JAX-RPC 2.0. Anne -Original Message- From: Liu, Scott [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 1:59 PM To: [EMAIL PROTECTED] Subject: RE: The Attributes and the UN-wrapper style Not that Axis does not support attributes at all it does support it in general. It just does not support it for the wrapper element, which is not really wrong since JAX-RPC spec specifies so. I could fix Axis to support it for this element which would be against the spec. I would like to know from our experts that why the JAX-RPC spec does not support it even though it is a such easy thing to do. I am also interested to know if Axis should support attributes on wrapper element if we do not use the wrapper style since the JAX-RPC does not mention anything on this. I have read comments on the topic from Anne Thomas Manes (http://www.burtongroup.com/weblogs/annethomasmanes/archives/cat_apache_ axis.html). It is very helpful in understanding encoding style and programming style. Thanks, Scott -Original Message- From: Peter White [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 6:36 AM To: [EMAIL PROTECTED] Subject: RE: The Attributes and the UN-wrapper style I have actually seen axis support document style (very close to wrapped) attributes in version 1.0 RC1... Here is a document-style encoded WSDL schema Snippet of a Email Add element: xs:simpleType name=EmailKind xs:restriction base=xs:string xs:enumeration value=Home/ xs:enumeration value=Work/ xs:enumeration value=Mobile/ xs:enumeration value=Other/ /xs:restriction /xs:simpleType xs:complexType name=EmailAddType xs:sequence xs:element name=email type=xs:string/ /xs:sequence xs:attribute name=emailKind use=required type=m1:EmailKind/ /xs:complexType When run through WSDL2Java, I get a class called EmailAddType with methods like getEmailKind and setEmailKind. The autogenerated deserializer knows that emailKind is coming in as an attribute and that email is coming in as a string. So when I make the request that has EmailAddType emailKind=Homeemail[EMAIL PROTECTED]/email/EmailAddType in it... Axis will deserialize it into an EmailAddType object with a stored email of [EMAIL PROTECTED] and an emailKind of Home The tricky things I've found are: That if I had named the attribute EmailKind instead of emailKind (and the email element Email)... The deserializer would have blown up because it didn't match a jax-rpc naming convention (lower case letters first in sub-elements of the complex request). Also, simple types don't maintain minoccurs and maxoccurs information. So xs:element name=email type=xs:string minOccurs=0/ would not register with WSDL2Java, and when you deploy your app to axis... It would show the WSDL without that minOccurs attribute. You'd have to work aroun it by using an ArrayOfEmails element and defining the limits there. Either way, it seems
RE: The Attributes and the UN-wrapper style
The JAX-RPC spec prohibits use of attributes as content of the wrapper element, but it says nothing regarding attributes as content of the elements which are children of the wrapper element. Many other implementations support attributes as content of the child elements. So this is prohibited: element name=wrapper complexType sequence element name=foo type=string/ /sequence attribute name=bar type=string/ /complexType /element But this should be okay: element name=wrapper complexType sequence element name=foo type=string/ element name=bar type=tns:bar/ /sequence /complexType /element complexType name=bar sequence element name=bat type=string/ /sequence attribute name=baz type=string/ /complexType Unfortunately, the WS-I Basic Profile doesn't talk about wrapped versus document style, so there's no definitive source of enlightenment for the correct way to implement wrapped style. Axis document style supports interoperability with .NET wrapped style when using attributes, so I don't view this as a serious problem, although obviously lack of support for attributes in the wrapper element reduces the ease of use of Axis. Given that code generated by a wsdl2java tool is always dependent on the associated SOAP engine, I don't see a breach of JAX-RPC compliance in this small area as a particularly bad thing. I think more seamless interoperability with .NET is always desirable. But I suspect that others might feel differently. I also suggest that folks submit feedback to the JAX-RPC Expert Group and request support for attributes in wrapped style in JAX-RPC 2.0. Anne -Original Message- From: Liu, Scott [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 1:59 PM To: [EMAIL PROTECTED] Subject: RE: The Attributes and the UN-wrapper style Not that Axis does not support attributes at all it does support it in general. It just does not support it for the wrapper element, which is not really wrong since JAX-RPC spec specifies so. I could fix Axis to support it for this element which would be against the spec. I would like to know from our experts that why the JAX-RPC spec does not support it even though it is a such easy thing to do. I am also interested to know if Axis should support attributes on wrapper element if we do not use the wrapper style since the JAX-RPC does not mention anything on this. I have read comments on the topic from Anne Thomas Manes (http://www.burtongroup.com/weblogs/annethomasmanes/archives/cat_apache_ axis.html). It is very helpful in understanding encoding style and programming style. Thanks, Scott -Original Message- From: Peter White [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 6:36 AM To: [EMAIL PROTECTED] Subject: RE: The Attributes and the UN-wrapper style I have actually seen axis support document style (very close to wrapped) attributes in version 1.0 RC1... Here is a document-style encoded WSDL schema Snippet of a Email Add element: xs:simpleType name=EmailKind xs:restriction base=xs:string xs:enumeration value=Home/ xs:enumeration value=Work/ xs:enumeration value=Mobile/ xs:enumeration value=Other/ /xs:restriction /xs:simpleType xs:complexType name=EmailAddType xs:sequence xs:element name=email type=xs:string/ /xs:sequence xs:attribute name=emailKind use=required type=m1:EmailKind/ /xs:complexType When run through WSDL2Java, I get a class called EmailAddType with methods like getEmailKind and setEmailKind. The autogenerated deserializer knows that emailKind is coming in as an attribute and that email is coming in as a string. So when I make the request that has EmailAddType emailKind=Homeemail[EMAIL PROTECTED]/email/EmailAddType in it... Axis will deserialize it into an EmailAddType object with a stored email of [EMAIL PROTECTED] and an emailKind of Home The tricky things I've found are: That if I had named the attribute EmailKind instead of emailKind (and the email element Email)... The deserializer would have blown up because it didn't match a jax-rpc naming convention (lower case letters first in sub-elements of the complex request). Also, simple types don't maintain minoccurs and maxoccurs information. So xs:element name=email type=xs:string minOccurs=0/ would not register with WSDL2Java, and when you deploy your app to axis... It would show the WSDL without that minOccurs attribute. You'd have to work aroun it by using an ArrayOfEmails element and defining the limits there. Either way, it seems
RE: The Attributes and the UN-wrapper style
I have actually seen axis support document style (very close to wrapped) attributes in version 1.0 RC1... Here is a document-style encoded WSDL schema Snippet of a Email Add element: xs:simpleType name=EmailKind xs:restriction base=xs:string xs:enumeration value=Home/ xs:enumeration value=Work/ xs:enumeration value=Mobile/ xs:enumeration value=Other/ /xs:restriction /xs:simpleType xs:complexType name=EmailAddType xs:sequence xs:element name=email type=xs:string/ /xs:sequence xs:attribute name=emailKind use=required type=m1:EmailKind/ /xs:complexType When run through WSDL2Java, I get a class called EmailAddType with methods like getEmailKind and setEmailKind. The autogenerated deserializer knows that emailKind is coming in as an attribute and that email is coming in as a string. So when I make the request that has EmailAddType emailKind=Homeemail[EMAIL PROTECTED]/email/EmailAddType in it... Axis will deserialize it into an EmailAddType object with a stored email of [EMAIL PROTECTED] and an emailKind of Home The tricky things I've found are: That if I had named the attribute EmailKind instead of emailKind (and the email element Email)... The deserializer would have blown up because it didn't match a jax-rpc naming convention (lower case letters first in sub-elements of the complex request). Also, simple types don't maintain minoccurs and maxoccurs information. So xs:element name=email type=xs:string minOccurs=0/ would not register with WSDL2Java, and when you deploy your app to axis... It would show the WSDL without that minOccurs attribute. You'd have to work aroun it by using an ArrayOfEmails element and defining the limits there. Either way, it seems Axis does have conventions for taking the attributes and just sneaking them into the objects created with a little this is an attribute of this type, not part of the sequence flag. In Wrapped you specify which parts go with the method in the WSDL by mapping the soap requests to the method invocations. (and in document, you have to make sure not to have more than one soap binding - message mapping with the same name, because the standard is less tightly bound) EmailAddType is contained in ArrayOfEmailAdds.. Which is contained in the CustomerAdd Element, which is what is used by the AddCustomerRequest element, which is mapped to the AddCustomer SOAP service. So yea, it sounds like you defintely want to stick with wrapped rather than RPC because the schema used in wrapper will define attributes... And I've actually seen wrapped attributes snuck into class objects by axis so I think if you just try it you'll be pleasantly surprised (or have you tried it and had it not work?), unless they removed the functionality in 1.1/1.2. -Original Message- From: Jeff Greif [mailto:[EMAIL PROTECTED] Sent: Friday, September 10, 2004 10:09 PM To: [EMAIL PROTECTED] Subject: Re: The Attributes and the UN-wrapper style A speculation (I'm not an expert): If you have wrapper someatt=somevalue part1.../part1 part2.../part2 /wrapper being converted to a method call on the server: ServiceClass.someMethod(part1, part2) the attributes are lost. There is no way in wsdl to specify parts which correspond to attributes in wsdl. As for using attributes in the non-wrapped implementation, in the wsdl, you cannot tell whether a document style service will be implemented as the wrapped form or the someMethod(wrapper) form, so the client would not be able to tell whether the attributes would be lost in the server or not. The implementation should be able to change transparently between the two forms without affecting the abstract description or the client. Jeff - Original Message - From: Liu, Scott [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 10, 2004 4:31 PM Subject: The Attributes and the UN-wrapper style Hi, All, There has been discussion about the wrapper style and the attributes in the past. And Axis does not support wrapper element attributes since JAX-RPC spec says that the wrapper element should not have attributes. I have no problem with it. But I do like people to clarify the following questions. 1. I know that it might be against the spec to have attributes for the wrapper element. But it is such a simple change on Axis to support attributes (I made minor change on client code generated with Axis tool and it worked) I am wondering why the JAX-RPC insists that there is no attributes for the wrapper element (.NET supports the attributes anyway
RE: The Attributes and the UN-wrapper style
Not that Axis does not support attributes at all it does support it in general. It just does not support it for the wrapper element, which is not really wrong since JAX-RPC spec specifies so. I could fix Axis to support it for this element which would be against the spec. I would like to know from our experts that why the JAX-RPC spec does not support it even though it is a such easy thing to do. I am also interested to know if Axis should support attributes on wrapper element if we do not use the wrapper style since the JAX-RPC does not mention anything on this. I have read comments on the topic from Anne Thomas Manes (http://www.burtongroup.com/weblogs/annethomasmanes/archives/cat_apache_ axis.html). It is very helpful in understanding encoding style and programming style. Thanks, Scott -Original Message- From: Peter White [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 6:36 AM To: [EMAIL PROTECTED] Subject: RE: The Attributes and the UN-wrapper style I have actually seen axis support document style (very close to wrapped) attributes in version 1.0 RC1... Here is a document-style encoded WSDL schema Snippet of a Email Add element: xs:simpleType name=EmailKind xs:restriction base=xs:string xs:enumeration value=Home/ xs:enumeration value=Work/ xs:enumeration value=Mobile/ xs:enumeration value=Other/ /xs:restriction /xs:simpleType xs:complexType name=EmailAddType xs:sequence xs:element name=email type=xs:string/ /xs:sequence xs:attribute name=emailKind use=required type=m1:EmailKind/ /xs:complexType When run through WSDL2Java, I get a class called EmailAddType with methods like getEmailKind and setEmailKind. The autogenerated deserializer knows that emailKind is coming in as an attribute and that email is coming in as a string. So when I make the request that has EmailAddType emailKind=Homeemail[EMAIL PROTECTED]/email/EmailAddType in it... Axis will deserialize it into an EmailAddType object with a stored email of [EMAIL PROTECTED] and an emailKind of Home The tricky things I've found are: That if I had named the attribute EmailKind instead of emailKind (and the email element Email)... The deserializer would have blown up because it didn't match a jax-rpc naming convention (lower case letters first in sub-elements of the complex request). Also, simple types don't maintain minoccurs and maxoccurs information. So xs:element name=email type=xs:string minOccurs=0/ would not register with WSDL2Java, and when you deploy your app to axis... It would show the WSDL without that minOccurs attribute. You'd have to work aroun it by using an ArrayOfEmails element and defining the limits there. Either way, it seems Axis does have conventions for taking the attributes and just sneaking them into the objects created with a little this is an attribute of this type, not part of the sequence flag. In Wrapped you specify which parts go with the method in the WSDL by mapping the soap requests to the method invocations. (and in document, you have to make sure not to have more than one soap binding - message mapping with the same name, because the standard is less tightly bound) EmailAddType is contained in ArrayOfEmailAdds.. Which is contained in the CustomerAdd Element, which is what is used by the AddCustomerRequest element, which is mapped to the AddCustomer SOAP service. So yea, it sounds like you defintely want to stick with wrapped rather than RPC because the schema used in wrapper will define attributes... And I've actually seen wrapped attributes snuck into class objects by axis so I think if you just try it you'll be pleasantly surprised (or have you tried it and had it not work?), unless they removed the functionality in 1.1/1.2. -Original Message- From: Jeff Greif [mailto:[EMAIL PROTECTED] Sent: Friday, September 10, 2004 10:09 PM To: [EMAIL PROTECTED] Subject: Re: The Attributes and the UN-wrapper style A speculation (I'm not an expert): If you have wrapper someatt=somevalue part1.../part1 part2.../part2 /wrapper being converted to a method call on the server: ServiceClass.someMethod(part1, part2) the attributes are lost. There is no way in wsdl to specify parts which correspond to attributes in wsdl. As for using attributes in the non-wrapped implementation, in the wsdl, you cannot tell whether a document style service will be implemented as the wrapped form or the someMethod(wrapper) form, so the client would not be able to tell whether the attributes would be lost in the server
The Attributes and the UN-wrapper style
Hi, All, There has been discussion about the wrapper style and the attributes in the past. And Axis does not support wrapper element attributes since JAX-RPC spec says that the wrapper element should not have attributes. I have no problem with it. But I do like people to clarify the following questions. 1. I know that it might be against the spec to have attributes for the wrapper element. But it is such a simple change on Axis to support attributes (I made minor change on client code generated with Axis tool and it worked) I am wondering why the JAX-RPC insists that there is no attributes for the wrapper element (.NET supports the attributes anyway)? Does anyone know the story behind this? 2. I did not read the whole JAX-RPC spec and so what I said might be wrong. Correct me if it is the case. Since attributes are such a big part of xml schema and if I use the attributes to go with the UN-wrapped style does Axis support it? My test revealed that it did not with v1.1. Is there a patch or will it be supported in Axis 1.2 for un-wrapped style? Your explanation is highly appreciated, Thanks, Scott
Re: The Attributes and the UN-wrapper style
A speculation (I'm not an expert): If you have wrapper someatt=somevalue part1.../part1 part2.../part2 /wrapper being converted to a method call on the server: ServiceClass.someMethod(part1, part2) the attributes are lost. There is no way in wsdl to specify parts which correspond to attributes in wsdl. As for using attributes in the non-wrapped implementation, in the wsdl, you cannot tell whether a document style service will be implemented as the wrapped form or the someMethod(wrapper) form, so the client would not be able to tell whether the attributes would be lost in the server or not. The implementation should be able to change transparently between the two forms without affecting the abstract description or the client. Jeff - Original Message - From: Liu, Scott [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 10, 2004 4:31 PM Subject: The Attributes and the UN-wrapper style Hi, All, There has been discussion about the wrapper style and the attributes in the past. And Axis does not support wrapper element attributes since JAX-RPC spec says that the wrapper element should not have attributes. I have no problem with it. But I do like people to clarify the following questions. 1. I know that it might be against the spec to have attributes for the wrapper element. But it is such a simple change on Axis to support attributes (I made minor change on client code generated with Axis tool and it worked) I am wondering why the JAX-RPC insists that there is no attributes for the wrapper element (.NET supports the attributes anyway)? Does anyone know the story behind this? 2. I did not read the whole JAX-RPC spec and so what I said might be wrong. Correct me if it is the case. Since attributes are such a big part of xml schema and if I use the attributes to go with the UN-wrapped style does Axis support it? My test revealed that it did not with v1.1. Is there a patch or will it be supported in Axis 1.2 for un-wrapped style? Your explanation is highly appreciated, Thanks, Scott
