You could use an OASIS catalog to make it available if you like.
On Tue, May 31, 2011 at 7:07 PM, David Sills <[email protected]> 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:[email protected]] > Sent: Tuesday, May 31, 2011 2:36 PM > To: [email protected] > 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 <[email protected]> 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:[email protected]] >> Sent: Tuesday, May 31, 2011 2:17 PM >> To: [email protected] >> 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 <[email protected]> >> 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:[email protected]] >>> Sent: Tuesday, May 31, 2011 12:41 PM >>> To: [email protected] >>> 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 <[email protected]> >>> 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 >>>> >>>> >>> >> >
