The whole idea behind WSDL is that you fully describe your types using XML Schema, and your client stub/proxy generator should be able to generate the appropriate language classes and serialization routines from the WSDL.
Unfortunately, the productivity aspects of client stub/proxy generators varies from tool to tool. .NET has a pretty powerful generator. SOAP Toolkit is pretty good, although not quite as powerful as .NET. WASP and GLUE can handle almost any data structure so long as it's properly defined by WSDL. Cape Clear has a nice GUI tool that you can use to map XML to Java classes. But some tools have a pretty limited capacity to handle complex types. Another problem is that the complex type containers used by Axis aren't especially compatible with the containers used by .NET. (WASP and GLUE use .NET-compatible containers by default.) If your service uses complex types, you might want to provide sample serialization routines. If your service requires headers, then you should definitely supply some sample header processing routines with your service. You might want to provide samples in multiple languages. To properly support full, automatic WSDL to PB language mappings, you pretty much need to build an full implementation of XML Schema. (that's why many implementations only provide partial support -- it's a big task) I might suggest that you start with Simon Fell's PocketSOAP WSDL compiler. It provides mappings to VB types. It might give you a head start. Anne > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 02, 2003 6:13 PM > To: [EMAIL PROTECTED] > Subject: RE: JAX-RPC Web Services in the Real World > > > > Thanks Anne, you provided the feedback I was looking for. I was thinking > that service providers might supply the Java stubs if they are using > JAX-RPC or the VB equivalent if using .Net just to save clients, who can > make use of them, time and hassle. Even for intranet Web service, it > seemed like a helpful approach. I'm working with PowerBuilder so we have > our own hurdle to jump in this regard. We want to make using Web services > as easy as possible. > > As for the JAX-RPC part, I was wondering if clients were required to > generate/use the JAX-RPC stubs in order to access a Web Service deployed > with Axis, but I can see that was the result of some muddled > thinking on my > part (too many cobwebs from holiday time off I think). > > I have a follow-up question related to custom datatypes, such as in the > Address example that comes with Axis (or at least it used to). If the > client generates JAX-RPC stubs (or .Net equivalent), they get classes > representing the custom datatypes; if they don't generate the stubs, my > guess is they are on their own to generate the classes needed, such as > would be used for the return type in the setReturnClass method in > Call.java. Is there another alternative? > > thanks, > Marion > > > > > "Anne Thomas > > Manes" To: > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED] cc: > > t> Subject: RE: JAX-RPC > Web Services in the Real > World > > 01/02/2003 > > 03:24 PM > > Please respond > > to axis-user > > > > > > > > > You should be able to make your Web services available simply by > publishing > the WSDL. Providing client stubs is much more problematic since > you have to > provide a stub that can run on the client side (a Java stub generated by > Axis isn't much help to a VB client). > > You can find quite a few demonstration services listed at www.xmethods.com. Most people are building services for specific business applications, though. These services often are not published to the world at large. They are made available to a select audience. You might advertise them in a private UDDI registry (so far UDDI is experiencing slow adoption). You might advertise them using WSIL. You might advertise them on your Web site. (Amazon and Google advertise theirs on their Web sites.) I'm not quite sure what you mean about JAX-RPC. JAX-RPC is the high-level API used in Axis. There's also a low level API if you'd prefer to manipulate the SOAP envelope directly. I imagine that most people use JAX-RPC. But here we're talking about the client API. It doesn't really apply to the way you implement the service. (perhaps you meant to ask about using RPC-style versus Document-style?) Anne > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 02, 2003 3:41 PM > To: [EMAIL PROTECTED] > Subject: JAX-RPC Web Services in the Real World > > > With so many of you offering your own web services (many of which seem > quite elaborate I might add), I'm wondering practicality of making these > services available. Are you simply making the WSDL available and leaving > it to the client to generate the client-side stubs or are you generating > the stubs for the client and making them available? And how are > you making > the WSDL or stubs available? Are you using UDDI or some other means? > > Also, I'm curious as to how many WS providers might be using Axis, but not > using JAX-RPC. Is that even allowed or desirable? > > Thanks for any and all feedback you can offer. > > Marion >
