Have you created a JIRA bug report? (make sure u try Axis 1.2 Beta first) -- dims
--- [EMAIL PROTECTED] wrote: > >>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... > > > === message truncated === ===== Davanum Srinivas - http://webservices.apache.org/~dims/
