If you like that paper I'll go you one better: http://www.research.microsoft.com/~emeijer/Papers/oopsla.pdf
Cheers! Rob -----Original Message----- From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 4:06 PM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design I see you've discovered the impedance mismatch between language types and XML types. For example, Java can't subclass by restriction -- only by extension (hence Axis's conversion of your string restriction to a string extension). Here's some interesting reading: http://www.cl.cam.ac.uk/~gmb/Papers/vanilla-xml2003.html It proposes making XML a first class language type. Anne -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 6:08 PM To: [EMAIL PROTECTED] Subject: RE: Need suggestions on web service interop and design >>Now, the task doing schemas first, makes sense..That way you won't get >>tempted to expose platform specific stuff..Great. Yeah, that's what I thought...wrong! Boy, I don't mean to complain (here it comes), but the folks developing web services have somehow missed the boat! Ok, you say that you should implement your schema first so you don't get bogged down in any particular implementation's specifics. Sounds good, I thought the same thing. Here's what I found. I found a nice program I liked for modeling my WSDL. Problem was, what does it matter how the schema is modeled if no development toolkit can properly generate from it? This is a big problem. For example, I tried Sun One Studio and found that when it generated proxy code, it dropped argument names from the methods/operations. What good is this? For example, say you have a method to reverse a string and optionally convert the case. Say it looks like: string StringHandler(string input, int caseConversionOption); Now, if the proxy had a method that looked like that, it would be fairly intuitive! But, alas, the names that ended up were more like: string StringHandler(string string1, int int1); Well, what good is that? How will a user know what the arguments are? Yeah right...I ain't doing any stinking doc, it should be self documenting! Next, I haven't used a toolkit yet that handles adding restrictions on arguments. For example, instead of merely having string arguments, I used simple types that inherited from base types (xsd:string in this example) that provided length restrictions. WSDL supports a maxLength restriction so I thought, and the WSDL modeling tool I used supported, specifying these would be good to enforce strings of the proper length. But, this has been nothing but a hassle. First, none of the generated proxy code classes to handle these types are very intuitive. For example, while the WSDL specifies that my special restricted types inherit from strings, the generated proxy classes for these special types do not inherit from their available string classes. Why? Because the languages I am working in (java, .NET), have final/sealed string classes preventing inheritance. Never noticed it before I started having trouble with it. I would love to hear why the language designers chose to prevent developers from inheriting from a string! And, even once you discover how to use the proxy generated class, still not a one of them has actually generated any code to enforce the restriction! I thought though, maybe one day the toolkits will be caught up and then it would have been good for me to design the schema that way...yeah right! So far for me, using complexTypes (not sure this is the correct term, but any type inheriting from a primitive type) has been nothing but a mistake. Avoid it like the plague. Next, I originally implemented my web service about 9 months ago in Axis 1.1. I don't really remember consciously choosing rpc/encoded versus doc/literal, but I ended up with rpc/encoded. Since I was implementing in Axis, this was probably a good choice. I have test clients in java that work just fine with it. But, woe is me, the time came I needed to consume my own web service in .NET. I thought, no problem. I have already consumed several others with Visual Studio.NET 2003, so no problem. When it works, I haven't seen a dev env yet that is easier to consume a web service with...yeah, I said "when it works". Ok, so I try to consume my own web service...and I can't. It doesn't work. How embarrassing, I can't even consume my own web service...but I expect everyone else to! I guess this answers the age old conundrum... "can God create a rock so heavy he can't lift it?" Yes, if he is using web services! ;-) I search message boards to no avail. So, I decide to use one of our precious free (included with MSDN subscription really) Microsoft support calls on this one. That was three weeks ago. After the second support guy toyed with my emotions by leading me to believe I could get a hotfix to remedy this, I had the rug pulled out from under me and now, no hotfix. I have been told that the basic problem is .NET will not support an rpc/encoded web service with argument types like I have. They look like: <xsd:simpleType name="messageText_t"> <xsd:restriction base="xsd:string"> <xsd:maxLength value="200"/> </xsd:restriction> </xsd:simpleType> in the original modeled wsdl, but they look like: <complexType name="messageText_t"> <simpleContent> <extension base="xsd:string" /> </simpleContent> </complexType> in the WSDL that Axis 1.1 spits out. If you end up with types that look like these, run! I have tried using both WSDLs (modeled and Axis generated) in VS.NET to generate proxy code, but neither works. So, 3 weeks after opening the support call, I have no other choice but to change my web service from rpc/encoded to doc/literal!!! MS says WS-I no longer supports rpc/encoded anyway. What a pain, I have to change the web service! Great, now we have a client redistribution problem. So, I decide alright, I'll changed the web service to doc/literal. Guess what, it doesn't work in Axis 1.1. The code generator works. I get no error. But, when I try to see the Axis produced WSDL by going to URL?wsdl, I get a java.lang.reflect.InvocationTargetException exception. Then I read where Axis 1.1 doesn't really support doc/literal that well, so I download Axis 1.2alpha. Guess what? It still doesn't work!!! So, now I have a MS/.NET environment that only likes doc/literal web services and a java environment that only likes rpc/encoded web services! And what are web services specifically meant to solve? Wasn't it interoperability? Good job, folks!!! I don't need a web service so my MS can talk to my MS and my java can talk to my java, but thanks for making it more complicated. ;-) So, you want suggestions? All animosity aside (thank God I am not bitter), here are my suggestions for web service success: 1. Do not use any types other than simple, primitive, types. 2. Co-develop in all required platforms at least the calling mechanism to ensure the web services can be called from all client platforms important to you. Otherwise you may end up stuck like I am. 3. Try to get paid by the hour while working on web services! ----- Original Message ----- Anne, Thanx for the fast info..Just the thing I needed. Now, the task doing schemas first, makes sense..That way you won't get tempted to expose platform specific stuff..Great. Maybe for once in a lifetime I should follow the .NET guides and do things the MS way :-) I can see that Axis 1.2 is alpha...Anyone knows of the beta or final release plans..? Best regards Henrik ----- Original Message ----- From: "Anne Thomas Manes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 14, 2004 3:38 PM Subject: RE: Need suggestions on web service interop and design > Henrik, > > The WS-I Basic Profile disallows the use of SOAP Encoding. It allows only > Document/Literal and RPC/Literal. Technically, WS-I BP doesn't *require* > support for RPC/Literal, though. Microsoft fought long and hard to exclude > RPC-style from the WS-I BP, but they lost that vote. In any case, Microsoft > does not support RPC/Literal, and my guess is that they will never support > RPC/Literal. (Please note, though, that the JAX-RPC specification requires > support for RPC/Literal.) > > If you want to design for interoperability, you should use Document/Literal. > Axis 1.2 provides much better support for Document/Literal than previous > releases. > > I suggest that you follow the .NET guides and define your schema first -- > then generate your beans from the schema. This approach ensures that you > won't attempt to expose Java collections through your WS interface. > > For best interoperability, your interface should consist of simple types, > arrays (defined using minOccurs/maxOccurs), and complex types defined as > sequence structures of simple types, arrays, and/or sequence structures. > > Anne > > -----Original Message----- > From: HG [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 14, 2004 3:43 AM > To: [EMAIL PROTECTED] > Subject: Need suggestions on web service interop and design > > Hi all > > I have developed some WebServices using Axis...nothing big...just a couple > of examples serializing beans and so between a java (Axis) server and a java > client...however...now a project is arising where web services is going to > be used in large scale... > > and to add even more complexity..the web services deployed must be > consumable by other platforms...first case is .NET > > I have read "inteop" guides in both "camps", ie Java/Axis/J2EE and .NET..In > the .NET camp they favor one style of messages and claim that this is > according to the WS-Basic profile...So it makes me wonder...how is Axis > support for this style (can't remember if it is doc/literal or rpc/literal) > ? > > In the .NET guides, thet also say that one must define the schemas first? > Why...? Because a schema can be understood by both sides? or to define the > message structure as they seem to favor message style instead of rpc style? > > The primary goal of the web servcices developed is to be consumable by many > platforms...first two targets is .NET and Axis...more coming.... > > > Any thoughts, ideas....Anne, please...you seem to have done a lot in this > fields.. > > Best regards > > Henrik > >
