But those two arguments are not mutually exclusive. SOAP is always going to be slower than RMI, no question. But by adopting SOAP as a facade for my application, do I not gain language-independence, flexibility, loose coupling and document-orientation?
What's wrong in thinking "code-centric" (don't like that term, but I'll continue usage for now) when designing my application and my API, but then generating a SOAP version of the API to gain all of those advantages? The only significant risk I see is that when designing my "code-centric" API, I may use language-specific artifacts, e.g., hashes in Perl, or Sets in Java. These structures may not translate well into other languages. But as long as I keep _that_ best practice in mind, I don't see an issue. In response to Anne's earlier mail, I understand the point about being able to identify which services use what data structures by looking at the schema usage, but the same determination can be made at least as easily by looking at your code (or its API or your documentation). Facetiously perhaps, I'd argue that basing that determination on the schema is actually the riskier approach because if you change the schema underneath me when I am looking at the WSDL, you break the contract I have with the service. Perhaps as Joe mentioned, we're just lazy, but that's not cause for apology. Laziness is the defining ethos of the programmer. Anand On Wed, 17 Nov 2004, 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:[EMAIL PROTECTED] : Sent: Tuesday, November 16, 2004 7:00 PM : To: [EMAIL PROTECTED] : 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:[EMAIL PROTECTED] : > Sent: Tuesday, November 16, 2004 1:19 PM : > To: [EMAIL PROTECTED] : > 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:[EMAIL PROTECTED] : > : Sent: Tuesday, November 16, 2004 8:57 AM : > : To: [EMAIL PROTECTED] : > : 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:[EMAIL PROTECTED]> : > : To: [EMAIL PROTECTED] : > : 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] : > : Sent: Tuesday, November 16, 2004 7:46 AM : > : To: [EMAIL PROTECTED] : > : 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 : > : : > : > . : > : :
