axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Plautz <j...@customcall.com>
Subject Re: Best Practice
Date Wed, 17 Nov 2004 15:16:24 GMT
It's language independence mostly. Non-Java gui front end talking to a 
Java back end(Yes, Corba may be a better alternative).

Actually this is one of the things that I battled over and over again 
personally. I really tried to be WSDL centric from the beginning. I 
really did. I knew that this was the intended standard. But, through the 
experience I've gained with AXIS(yes I know AXIS isn't everything) I 
found that it was much easier to start with code then it was to start 
with a WSDL. Maybe it was the approach I was taking, but it seemed more 
intuitive to create the code and generate the WSDD then expose it as a 
service(through a facade) then to create a WSDL then generate the 
service code and then tie it all together. I found when requirements 
changed(yes, requirements do change) I was having to make a lot more 
code and configuration adjustments when using a WSDL approach vs the 
code approach.

I guess you could call me lazy for not wanting to do more work.

Joe

Anne Thomas Manes wrote:
> Code centricity is a fine approach if your goal is to use SOAP as a slower
> replacement for RMI -- producing tightly coupled Java-centric distributed
> object applications. (But why not just use RMI?)
> 
> If your goal is to develop language-independent, flexible, loosely coupled,
> document-oriented, SOA environments, then you should take a WSDL-centric
> approach.
> 
> Anne 
> 
> -----Original Message-----
> From: Joe Plautz [mailto:joep@customcall.com] 
> Sent: Tuesday, November 16, 2004 7:00 PM
> To: axis-user@ws.apache.org
> Subject: Re: Best Practice
> 
> Be code centric as opposed to WSDL centric. With Axis we can expose our 
> code in a relatively easy manner without the need of creating a WSDL 
> first which is perfect.
> 
> 
> Anne Thomas Manes wrote:
> 
>>I'm thinking about reusability. 
>>
>>Picture yourself a couple of years from now when your company has a few
>>thousand services deployed. Like most companies you have about half dozen
> 
> or
> 
>>so data structures that represent customer information. And now you want
> 
> to
> 
>>find services that use a particular "customer" format. 
>>
>>If you have defined each of your various customer formats as separate
>>schemas, then each customer element has a unique Qname, at which point you
>>can search for services that use the abc:Customer as opposed to the
>>xyz:Customer. 
>>
>>If you have defined the customer element repeatedly in every web service,
>>you have no way to search for services that use one format versus another
>>without doing a detailed analysis of each WSDL file.  
>>
>>Anne
>>
>>-----Original Message-----
>>From: Anand Natrajan [mailto:an4m@cs.virginia.edu] 
>>Sent: Tuesday, November 16, 2004 1:19 PM
>>To: axis-user@ws.apache.org
>>Subject: RE: Best Practice
>>
>>While I understand the attraction to factor out common definitions into a
>>separate schema file, I am a bit conflicted about the use of schema files
>>within a WSDL for describing a service.
>>
>>If your WSDL imports a schema, you can no longer hand out a single file to
>>your customers and ask them to generate clients for your service; you must
>>hand out the schema files as well. Giving out multiple files seems clunky.
>>
>>Some of you may counter that I shouldn't be pamphleteering my WSDLs
> 
> directly
> 
>>anyway; customers should use the service URL followed by "?wsdl" or some
>>such device to get at the WSDL. While such devices may resolve imports (if
>>they do), that doesn't solve the problem entirely. What if my service is
>>published redundantly, i.e., what if multiple servers can serve a client?
>>
>>In such cases, the customer could copy over the WSDL, change the service
> 
> URL
> 
>>to reflect another server and access the service. Ah, but now, the
> 
> customer
> 
>>has a version of the WSDL that is different from what I have on the server
>>side, which could lead to interoperability problems later.
>>
>>So what's my approach? Much as there is talk about writing WSDLs first, I
>>prefer generating them automatically. I can do all the refactoring I want
> 
> in
> 
>>my Java code and trust the java2wsdl generator to generate non-import
> 
> WSDLs.
> 
>>Except for cosmetic changes (copyrights, formatting, etc.) I don't touch
> 
> the
> 
>>WSDLs after that. This way I can control what WSDL the server and clients
>>use.
>>
>>Perhaps my approach is heresy. If it is, I'd like to know how my concerns
>>can be countered. Thanks!
>>
>>Anand
>>
>>On Tue, 16 Nov 2004, Anne Thomas Manes wrote:
>>
>>: Technically, an "import" is importing a namespace, not the schema or
> 
> WSDL
> 
>>: file that creates the namespace.
>>: The WS-I Basic Profile says that you must not coerce (i.e., change) the
>>: namespace name during import:
>>: 5.1.9 Namespace Coercion
>>: Namespace coercion on wsdl:import is disallowed by the Profile.
>>: R2005 The targetNamespace attribute on the wsdl:definitions element of a
>>: description that is being imported MUST have same the value as the
>>namespace
>>: attribute on the wsdl:import element in the importing DESCRIPTION.
>>:
>>: In other words, if the imported WSDL file has a target namespace of
>>: "urn:foo", when you import it, you must do so by saying:
>>:    <wsdl:import namespace="urn:foo" location="http://foo-url" />
>>: and you can't change the namespace to
>>:    <wsdl:import namespace="urn:foobar" location="http://foo-url" />
>>:
>>: In addition, you must declare the namespace to reference any elements
>>within
>>: the namespace:
>>:   xmlns:foo="urn:foo"
>>:
>>: The same goes for schema imports.
>>:
>>: Anne
>>:
>>:   _____
>>:
>>: From: HG [mailto:axis@websolver.dk]
>>: Sent: Tuesday, November 16, 2004 8:57 AM
>>: To: axis-user@ws.apache.org
>>: Subject: Re: Best Practice
>>:
>>: Hi Anne
>>:
>>: Thanx for your fantastic reply/comments on this post. They really makes
>>: sence.
>>:
>>: Actually I used your suggestions already (maybe without knowing it ??!)
> 
> on
> 
>>a
>>: small-sized project where I only had one xsd file for all types. The
> 
> whole
> 
>>: "domain model" in one file.
>>:
>>: BTW, do you know that WS-I Basic Profile suggests according to schema
>>: imports and wsdl imports in respect to namespaces.?
>>:
>>: /Henrik
>>:
>>: ----- Original Message -----
>>: From: Anne Thomas Manes <mailto:anne@manes.net>
>>: To: axis-user@ws.apache.org
>>: Sent: Tuesday, November 16, 2004 2:45 PM
>>: Subject: RE: Best Practice
>>:
>>: Typically I prefer not to use a bunch of different schemas with a
> 
> service
> 
>>: (e.g., one schema for each element and type). In order to reference an
>>: element (or type) from one schema (a) in another schema (b), you must
>>: explicitly import the (a) schema (and define a namespace declaration)
> 
> into
> 
>>: the (b) schema using <xsd:import>. Likewise, if the (b) schema needs to
>>: reference an element or type from the (a) schema, you must also
> 
> explicitly
> 
>>: import the (a) schema in the (b) schema. So using lots of separate
> 
> schemas
> 
>>: requires lots of schema imports.
>>:
>>: I suggest you factor schemas into the appropriate sizes to support your
>>: requirements for reusability. In other words, if you plan to use a
>>: particular element (or type) in a number of different applications,
>>: combining the element with a different set of elements in each
>>application,
>>: then it makes sense to define it in a separate schema. But if you
>>typically
>>: use that element with the same group of elements in most of your
>>: applications, then you probably want to define them in the same schema.
>>:
>>: My recommendation, therefore, is to define your service's data elements
>>: (customer, purchase order, etc) and their types in a single schema
> 
> unless
> 
>>: you have a compelling reason to factor them into separate schemas.
>>:
>>: I also recommend that you follow Henrik's advice to define your
> 
> service's
> 
>>: input and output message elements in a separate schema from your data
>>: element schema. (You will need to <xsd:import> your data element schema
>>into
>>: the message element schema.) If the particular set of message elements
>>will
>>: be used only by your service, then you can define them within the
> 
> <types>
> 
>>: section of your WSDL. (This situation is reasonably typical because the
>>: input message element usually has the same name as the operation so
> 
> tends
> 
>>to
>>: be pretty unique to the particular service). But if you anticipate that
>>you
>>: may have multiple services that wish to exchange the same messages, then
>>you
>>: probably want to factor the message elements into a standalone schema. I
>>: suspect you're more likely to reuse fault messages than input and output
>>: messages, so it makes sense to factor fault messages into a separate
>>schema.
>>:
>>:
>>: Note that a WSDL document may have at most only one <types> section, so
>>you
>>: can't <wsdl:import> multiple types sections into a WSDL document. If you
>>: want to import multiple schemas, you must import them from within your
>>: <types> section, and you must use <xsd:import> to do so.
>>:
>>: Regards,
>>: Anne
>>:
>>:
>>:   _____
>>:
>>: From: tony.q.weddle@gsk.com [mailto:tony.q.weddle@gsk.com]
>>: Sent: Tuesday, November 16, 2004 7:46 AM
>>: To: axis-user@ws.apache.org
>>: Subject: Re: Best Practice
>>:
>>: Thanks, Henrik.
>>: That's the sort of thing I'm after.
>>: I couldn't quite work out the difference between 1 and 2, though. In 1,
>>you
>>: are defining the messages for the service methods and this naturally
>>: includes the parameters of the methods. In 2, it seems you're doing the
>>same
>>: thing again (except for the message elements themselves).
>>: When importing, are you referring to WSDL imports or XML schema imports?
>>We
>>: have some services that define a schema in the <types> element and
> 
> import
> 
>>: another schema, in the <types> element also. The latest SOAPscope
> 
> doesn't
> 
>>: like this, unless the imported schema is imported within the schema
> 
> which
> 
>>: references its types. Just thought I'd mention it (XMLSpy, doesn't
> 
> mind).
> 
>>: Keep it coming!
>>: Tony
>>:
>>:
>>: Hi Tony
>>:
>>: I have a few...Some on this list might disagree, but it is always nice
>>with
>>: a discussion.
>>:
>>: I have done this, on several projects, and it works very well,
> 
> especially
> 
>>: for interop.
>>: The main point is: Use Schemas
>>:
>>: 1.
>>: Define a schema for each message you want your webservice to process.
>>: Lets call these schemas for message-schemas.
>>:
>>: 1 a)
>>: Typically a "call" to a webservice consists of some input message and
>>maybe
>>: some output message. Define a schema for both.
>>: 1 b)
>>: When you define the schema for the messages, the "value objects" will
>>: logically appear to you. Value objects in this context is types (defined
>>in
>>: schemas) for parameters you pass in the message and return values of the
>>: message.
>>:
>>: Outcome of 1:
>>: You have a schema for each webservice that exactly defines
>>request/response
>>: messages for each web service method.
>>:
>>: 2.
>>: As pointed out in 1 b) schemas for the parameter/return types can/must
>>also
>>: be defined. This might be an Order type, Customer type, etc.
>>: Lets call these schemas for type-schemas.
>>: 2 a)
>>: Define these parameter/return types in a schema, too.
>>:
>>: Outcome of 2:
>>: You have a schema (or all in one schema) for each parameter/return type
>>that
>>: each webservice method must be able to process.
>>: Over time you'll have a "domain model" of types/classes described in
>>: schemas.
>>:
>>: 3.
>>: Use imports between schemas (both type-schemas and message-schemas) to
>>: construct your WSDL document.
>>: a) Import type-schemas in your message-schemas as needed by
>>parameter/return
>>: types.
>>: b) Import message-schemas in your WSDL document as needed.
>>:
>>: Outcome of all three:
>>: - You have a clean separation and description (in terms of schemas) of
> 
> the
> 
>>: services a webservice provides and the "types of data" these service
>>: operates on.
>>: - Your WSDL doesn't get cluttered with types
>>:
>>: Anyone... comments on these steps are welcome...
>>:
>>: Regards
>>:
>>: Henrik
>>:
>>
>>.
>>
> 
> 
> .
> 

Mime
View raw message