RE: Schemas inside WSDL

[David Sills <DS...@datasourceinc.com>]

Benson:

Oh, yes, I knew I'd have to hand-craft the schema. That wasn't a problem - it already exists and is available. However, enabling schema validation had a side effect I didn't foresee. The package "schema" for my classes was, of course, not available (since it doesn't exist, technically, at least not as a schema with the appropriate URL), and so the whole thing threw a hissy fit. In the end, I decided you were right and not to try to use schema validation. I'll just validate the old fashioned way on the other end.

Many thanks for your help and the clarifications.

David Sills


-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com] 
Sent: Tuesday, May 31, 2011 2:36 PM
To: users@cxf.apache.org
Subject: Re: Schemas inside WSDL

David,

There's some more underbrush that I see the need to clear away.

Strictly speaking, a WSDL specifies the operations of a service. In
specifying those operations, it specifies the types of the operands.
The language in which it specifies those types is W3C XML Schema.

A WSDL (and embedded or reference schema(s)) is either something you
create, or something you generate from your code, using JAX-B or one
of the alternatives.

If you specify that, say, a parameter has to be a positive integer,
JAX-B does not attempt to map this into your Java code at all. There
is no corresponding @nnotation for it.

However, if you enable schema validation, CXF (or some other lib) will
validate your numbers against the schema. It might or might not be too
slow for you.

So, I want to draw a distinction between validation and structural
complexity. If you use restrictions in a schema to tighten the
contract, that's fine. JAX-B will (generally) map them to simple Java
constructs, and then you can choose to enable schema validation at
runtime and get exceptions thrown for transgressions. You might or
might not like *when* they get thrown, or how slow the validation is.
You will have to build them by typing your own XSD files that you
reference in your WSDL files, not by adding @nnotations to Java.

On the other hand, building up a very complex schema ('mixed', or
attributes, or other things that are very specific to XML syntax and
very far away from Java or other programming languages) is likely to
give you unpleasant surprises.




On Tue, May 31, 2011 at 2:26 PM, David Sills <DS...@datasourceinc.com> wrote:
> Benson:
>
> It would seem that I sort-of did follow you (assuming I follow you now), though my email wasn't quite fast enough (or my brain wasn't, take your pick).
>
> However, I'm a little perplexed about why it is that using a schema type that guarantees data validation would be a bad idea. I'm not concerned with my data's structure so much as its content. I'd like the failure to occur at the earliest possible moment in the web service process, as I anticipate a heavy load for this application. That was why I thought that if the original parser that got the WSDL could fail while loading the XML document (ignoring for the moment that it is a WSDL and has other responsibilities) that it might help me: no Java objects and less processing time.
>
> Still, I take your notion of separation of concerns (assuming that's actually what you meant). Let the WSDL just get the data to me and then worry about whether it is valid or not.
>
> David
>
>
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Tuesday, May 31, 2011 2:17 PM
> To: users@cxf.apache.org
> Subject: Re: Schemas inside WSDL
>
> Let me be clear about what I'm discouraging versus merely describing.
>
> Once upon a time, SOAP had these two models: RPC and Document. The
> idea was that RPC would be used a mapping for procedure calls, and
> Document was about passing XML documents around.
>
> As things have evolved, however, the RPC format is pretty completely
> dead. However, the vast majority of what people do with web services
> is, in fact, RPC. They are just doing it with Document/Literal
> services.
>
> As a result, what most people are doing most of the time is passing
> data structures around, often between disparate programming languages.
> This works best when the XML used is the simplest possible XML that
> carries the semantics. So, while an XML Schema can talk about
> attributes, and facets, and regexp restrictions, and all sorts of
> peanut-butter hoola-hoops, I think I am not alone in discouraging the
> use of complex schemata in web services. If your actual purpose is to
> ship complex chunks of XML around the landscape, I'd recommend sending
> them at attachments.
>
> So, OK, let's imagine that you think that I'm making sense. "What
> about reuse?" you ask. Reuse is a good thing. However, it's very hard
> to achieve reuse if you define your schema by asking JAX-B to derive
> it from an infestation of @nnotation sn@ils in your Java code. If you
> want reuse, I personally think you are better off defining your
> service as a WSDL that includes XML schema(s) that you can maintain
> and share, and then generating the Java code from the schema, instead
> of the other way around.
>
>
>
>
> On Tue, May 31, 2011 at 2:02 PM, David Sills <DS...@datasourceinc.com> wrote:
>> Benson:
>>
>> I take your point that perhaps I'm asking more than the tools can do, but am left wondering why you might discourage the use of reusable elements within a web service. Is it not typically done? I was thinking that it would simplify data validation - by the time you made it through a schema-aware parser, you would know that the data would be valid as well as correctly formatted.
>>
>> Ah well, at least apples and coconuts does seem like a tasty combo to me personally... :-)
>>
>> David
>>
>>
>> -----Original Message-----
>> From: Benson Margulies [mailto:bimargulies@gmail.com]
>> Sent: Tuesday, May 31, 2011 12:41 PM
>> To: users@cxf.apache.org
>> Subject: Re: Schemas inside WSDL
>>
>> David,
>>
>> I think you are mixing apples and coconuts a bit here.
>>
>> The schema in a WSDL is XSD. What you are looking at it the process of
>> auto-generating XSD from Java with annotations, apparently with JAX-B.
>>
>> JAX-B supports only a subset of XSD. Many restrictions and other
>> refinements that you can express in XSD have no representation in
>> plain JAX-B. In some cases you can add JAX-B plugins that get you
>> more.
>>
>> If you use the JAX-B tool to generate Java from your XSD, you can see
>> just how much gets thrown away.
>>
>> If you really need to use a highly-specialized schema to express your
>> web service (which I might discourage), you can't use JAX-B in
>> Java-first mode. You can use schema-first, and then enable schema
>> validation.
>>
>>
>> On Tue, May 31, 2011 at 11:21 AM, David Sills <DS...@datasourceinc.com> wrote:
>>> I'm having some trouble understanding exactly how to relate XSD types I
>>> already have to WSDL, where I want to reuse them. If someone could point
>>> me in a good direction, I'd be very grateful.
>>>
>>> I have, for instance, a schema in which I define:
>>>
>>>  <xs:simpleType name="ssn-type">
>>>    <xs:restriction base="xs:string">
>>>      <xs:pattern
>>> value="[1-8][0-9]{8}|(?:0(?!0{8}))[0-9]{8}|(?:9(?!9{8}))[0-9]{8}"/>
>>>    </xs:restriction>
>>>  </xs:simpleType>
>>>
>>> (a standard SSN but not all 0s or all 9s - this is the customer's
>>> requirement)
>>>
>>> I would like to use this to validate the SSN (in the WSDL, in other
>>> words) for this class:
>>>
>>> @XmlType(name = "Identity")
>>> public class IdentityImpl implements Identity
>>> {
>>>        private String ssn;
>>> // a bunch of other properties
>>>
>>>        /**
>>>         * @see com.datasourceinc.abis.ws.fingerprint.Identity#getSsn()
>>>         */
>>>        @Override
>>>        public String getSsn()
>>>        {
>>>                return ssn;
>>>        }
>>>
>>>        public void setSsn(String ssn)
>>>        {
>>>                this.ssn = ssn;
>>>        }
>>> // the rest of the getters and setters
>>>
>>> I have tried a variety of annotations on the getSsn() method and the
>>> entire class without success. Can anyone suggest anything that will do
>>> what I want?
>>>
>>> Thanks!
>>>
>>> David Sills
>>>
>>>
>>
>

Re: Schemas inside WSDL

[Benson Margulies <bi...@gmail.com>]

You could use an OASIS catalog to make it available if you like.

On Tue, May 31, 2011 at 7:07 PM, David Sills <DS...@datasourceinc.com> wrote:
> Benson:
>
> Oh, yes, I knew I'd have to hand-craft the schema. That wasn't a problem - it already exists and is available. However, enabling schema validation had a side effect I didn't foresee. The package "schema" for my classes was, of course, not available (since it doesn't exist, technically, at least not as a schema with the appropriate URL), and so the whole thing threw a hissy fit. In the end, I decided you were right and not to try to use schema validation. I'll just validate the old fashioned way on the other end.
>
> Many thanks for your help and the clarifications.
>
> David Sills
>
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Tuesday, May 31, 2011 2:36 PM
> To: users@cxf.apache.org
> Subject: Re: Schemas inside WSDL
>
> David,
>
> There's some more underbrush that I see the need to clear away.
>
> Strictly speaking, a WSDL specifies the operations of a service. In
> specifying those operations, it specifies the types of the operands.
> The language in which it specifies those types is W3C XML Schema.
>
> A WSDL (and embedded or reference schema(s)) is either something you
> create, or something you generate from your code, using JAX-B or one
> of the alternatives.
>
> If you specify that, say, a parameter has to be a positive integer,
> JAX-B does not attempt to map this into your Java code at all. There
> is no corresponding @nnotation for it.
>
> However, if you enable schema validation, CXF (or some other lib) will
> validate your numbers against the schema. It might or might not be too
> slow for you.
>
> So, I want to draw a distinction between validation and structural
> complexity. If you use restrictions in a schema to tighten the
> contract, that's fine. JAX-B will (generally) map them to simple Java
> constructs, and then you can choose to enable schema validation at
> runtime and get exceptions thrown for transgressions. You might or
> might not like *when* they get thrown, or how slow the validation is.
> You will have to build them by typing your own XSD files that you
> reference in your WSDL files, not by adding @nnotations to Java.
>
> On the other hand, building up a very complex schema ('mixed', or
> attributes, or other things that are very specific to XML syntax and
> very far away from Java or other programming languages) is likely to
> give you unpleasant surprises.
>
>
>
>
> On Tue, May 31, 2011 at 2:26 PM, David Sills <DS...@datasourceinc.com> wrote:
>> Benson:
>>
>> It would seem that I sort-of did follow you (assuming I follow you now), though my email wasn't quite fast enough (or my brain wasn't, take your pick).
>>
>> However, I'm a little perplexed about why it is that using a schema type that guarantees data validation would be a bad idea. I'm not concerned with my data's structure so much as its content. I'd like the failure to occur at the earliest possible moment in the web service process, as I anticipate a heavy load for this application. That was why I thought that if the original parser that got the WSDL could fail while loading the XML document (ignoring for the moment that it is a WSDL and has other responsibilities) that it might help me: no Java objects and less processing time.
>>
>> Still, I take your notion of separation of concerns (assuming that's actually what you meant). Let the WSDL just get the data to me and then worry about whether it is valid or not.
>>
>> David
>>
>>
>>
>> -----Original Message-----
>> From: Benson Margulies [mailto:bimargulies@gmail.com]
>> Sent: Tuesday, May 31, 2011 2:17 PM
>> To: users@cxf.apache.org
>> Subject: Re: Schemas inside WSDL
>>
>> Let me be clear about what I'm discouraging versus merely describing.
>>
>> Once upon a time, SOAP had these two models: RPC and Document. The
>> idea was that RPC would be used a mapping for procedure calls, and
>> Document was about passing XML documents around.
>>
>> As things have evolved, however, the RPC format is pretty completely
>> dead. However, the vast majority of what people do with web services
>> is, in fact, RPC. They are just doing it with Document/Literal
>> services.
>>
>> As a result, what most people are doing most of the time is passing
>> data structures around, often between disparate programming languages.
>> This works best when the XML used is the simplest possible XML that
>> carries the semantics. So, while an XML Schema can talk about
>> attributes, and facets, and regexp restrictions, and all sorts of
>> peanut-butter hoola-hoops, I think I am not alone in discouraging the
>> use of complex schemata in web services. If your actual purpose is to
>> ship complex chunks of XML around the landscape, I'd recommend sending
>> them at attachments.
>>
>> So, OK, let's imagine that you think that I'm making sense. "What
>> about reuse?" you ask. Reuse is a good thing. However, it's very hard
>> to achieve reuse if you define your schema by asking JAX-B to derive
>> it from an infestation of @nnotation sn@ils in your Java code. If you
>> want reuse, I personally think you are better off defining your
>> service as a WSDL that includes XML schema(s) that you can maintain
>> and share, and then generating the Java code from the schema, instead
>> of the other way around.
>>
>>
>>
>>
>> On Tue, May 31, 2011 at 2:02 PM, David Sills <DS...@datasourceinc.com> wrote:
>>> Benson:
>>>
>>> I take your point that perhaps I'm asking more than the tools can do, but am left wondering why you might discourage the use of reusable elements within a web service. Is it not typically done? I was thinking that it would simplify data validation - by the time you made it through a schema-aware parser, you would know that the data would be valid as well as correctly formatted.
>>>
>>> Ah well, at least apples and coconuts does seem like a tasty combo to me personally... :-)
>>>
>>> David
>>>
>>>
>>> -----Original Message-----
>>> From: Benson Margulies [mailto:bimargulies@gmail.com]
>>> Sent: Tuesday, May 31, 2011 12:41 PM
>>> To: users@cxf.apache.org
>>> Subject: Re: Schemas inside WSDL
>>>
>>> David,
>>>
>>> I think you are mixing apples and coconuts a bit here.
>>>
>>> The schema in a WSDL is XSD. What you are looking at it the process of
>>> auto-generating XSD from Java with annotations, apparently with JAX-B.
>>>
>>> JAX-B supports only a subset of XSD. Many restrictions and other
>>> refinements that you can express in XSD have no representation in
>>> plain JAX-B. In some cases you can add JAX-B plugins that get you
>>> more.
>>>
>>> If you use the JAX-B tool to generate Java from your XSD, you can see
>>> just how much gets thrown away.
>>>
>>> If you really need to use a highly-specialized schema to express your
>>> web service (which I might discourage), you can't use JAX-B in
>>> Java-first mode. You can use schema-first, and then enable schema
>>> validation.
>>>
>>>
>>> On Tue, May 31, 2011 at 11:21 AM, David Sills <DS...@datasourceinc.com> wrote:
>>>> I'm having some trouble understanding exactly how to relate XSD types I
>>>> already have to WSDL, where I want to reuse them. If someone could point
>>>> me in a good direction, I'd be very grateful.
>>>>
>>>> I have, for instance, a schema in which I define:
>>>>
>>>>  <xs:simpleType name="ssn-type">
>>>>    <xs:restriction base="xs:string">
>>>>      <xs:pattern
>>>> value="[1-8][0-9]{8}|(?:0(?!0{8}))[0-9]{8}|(?:9(?!9{8}))[0-9]{8}"/>
>>>>    </xs:restriction>
>>>>  </xs:simpleType>
>>>>
>>>> (a standard SSN but not all 0s or all 9s - this is the customer's
>>>> requirement)
>>>>
>>>> I would like to use this to validate the SSN (in the WSDL, in other
>>>> words) for this class:
>>>>
>>>> @XmlType(name = "Identity")
>>>> public class IdentityImpl implements Identity
>>>> {
>>>>        private String ssn;
>>>> // a bunch of other properties
>>>>
>>>>        /**
>>>>         * @see com.datasourceinc.abis.ws.fingerprint.Identity#getSsn()
>>>>         */
>>>>        @Override
>>>>        public String getSsn()
>>>>        {
>>>>                return ssn;
>>>>        }
>>>>
>>>>        public void setSsn(String ssn)
>>>>        {
>>>>                this.ssn = ssn;
>>>>        }
>>>> // the rest of the getters and setters
>>>>
>>>> I have tried a variety of annotations on the getSsn() method and the
>>>> entire class without success. Can anyone suggest anything that will do
>>>> what I want?
>>>>
>>>> Thanks!
>>>>
>>>> David Sills
>>>>
>>>>
>>>
>>
>