Doug Hoople

Hi Guadalupe,

In this case, you DO have to use the object creation syntax and use the complextype name, "WeatherSummary" for this.

For example,

WeatherSummary ws = new WeatherSummary();
ws.location = "NY";
ws.wind = "25";
ws.sky = "clear";
ws.temp = "56";
ws.humidity = "65";
ws.pressure = "1011";
ws.visibility = "2miles";

Then, you'd invoke a method like setWeatherInfo as follows:

setWeatherInfo(ws);

If you're receiving this as a return type, you'd declare and use as follows:

WeatherSummary ws;
ws = getWeatherInfo(today); // returns a single weather summary

Or, if it's an array of user-defined types

WeatherSummary [] ws;
ws = getWeatherInfo(today,5); // returns array of 5 summaries

Thanks.
Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

Hi Kumar,

What WSAD is doing under the wizard's covers is basically running Java2WSDL. So again, define your class, have it implement Serializable (as is done in the Weather example), and then run it through Java2WSDL. You should then have a usable input to all the rest of the cycle.

Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

Well maybe not quite so obvious. I found the problem, or at least the problem points.

The secret's in the webservices.xml file, which is specified through JSR-109. For a really good general description of all the file mappings from WSDL through webservices.xml and jaxrpcmapping.xml file and finally back to the web.xml file, take a look at:

http://www-128.ibm.com/developerworks/library/ws-jsrart/

In this article, they literally point at the mappings required to make it all work. In my case the two key elements were in the <port-component> section of the webservices.xml file:

<service-endpoint-interface>itso.bean.WeatherForecast</service-endpoint-interface>
<service-impl-bean id="ServiceImplBean_1071529026058">
<servlet-link>itso_bean_WeatherForecast</servlet-link>
</service-impl-bean>

and the <servlet-link> element refers to a section of the web.xml file, which in this case looks like:

<servlet>
<servlet-name>itso_bean_WeatherForecast</servlet-name>
<servlet-class>itso.bean.WeatherForecast</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

Refocusing, note that the <service-endpoint-interface> points to a class (itso.bean.WeatherForecast), and that this will resolve to the <servlet-class> class itso.bean.WeatherForecast (whoa, dude, that doesn't sound right!). Two problems here: 1) These two references point to the same class, and, more importantly, 2) what's supposed to be pointing to an interface is actually pointing to a class.

Apparently the <service-endpoint-interface> needs to point to an interface, so building a Web Service from a class instead of an interface (as instructed on p. 253 of the Redbook "Select the WeatherForecast class...") is 1) wrong and 2) the only way the wizard will let you do it.

In my book, that's a bug. Easily solved, though... Build the Web Service as described, then change the class to an interface of the same name, and paste the implementation into a new class in the same package. Fix the web.xml <servlet-class> so that it loads your new implementation class instead of the interface and VOILA! your problem is solved.

Simple, no? NO.

At least now I'm in better control of JSR-109.

Thanks.
Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4
[ January 19, 2005: Message edited by: Doug Hoople ]

If you make the classes implement the Serializable interface, then the rest should take care of itself. There's an example of this in the Redbook Weather Service, where the user-defined datatype Weather is passed in and passed out, both in unit form and in array form. The only thing I can see enabling this is the Serializable implementation.

I know that the Redbook examples are for WebSphere, but the download does contain fully blown-out versions of their resulting services, and they're JAX-RPC (JSR 109) compliant, so they should work with the other frameworks as well.

Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

Hi Guadalupe,

I took my own advice, ran the stub generator and, boy, was I ever wrong. The data structure you were asking about was a garden-variety string, after all.

And you were right, it is pretty simple. Assuming that the method you're calling is getAirportInfo, then you'd simply pass a string for the getInfo parameter (the element that defines CountryAbbrviation).

The stub's interface method declaration would look like this:

public String getAirportInfo(String CountryAbbrviation);

And you'd call it with the following (again assuming you'd already loaded up your proxy reference):

String airportInfo;
String countryCode = "UK";
airportInfo = proxy.getAirportInfo(countryCode);

Hope this helps. Sorry to have misled you.

Thanks.
Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

OK Rancheros...

I give up. I'm using the trial version of WebSphere Application Developer 5.1, and almost all of my JavaBean to WebService attempts give me an InstantiationException in the end.

I've created all the other Redbook variants, EJB bottom-up, JavaBean top-down, EJB bottom-up with JMS, URL (servlet), DADX, so I must be doing something right. I've generated all the test clients in all their glorious forms.

But when I try the simplest of all the Web Service generation demonstrations (the first one in Chapter 15 of the Redbook), bottom-up JavaBean, I keep running into the same wall. I've tried a variety of different dumbed-down "JavaBean" classes, and I've observed all the rules (public constructor, getters/setters, Dynamic Web Project, ...), but they all give me the same grief.

I HAVE, however, reversed the cycle, generated a JavaBean skeleton from WSDL, made the quick mods for a "HelloWorld" and had it turn out fine (!!! :-((((). That would be great if it led to the revelation about the missing piece, but it didn't. Oddly enough, it worked when the exported "class" was an interface that extended java.rmi.Remote, implemented immediately by a <MyClass>SoapBindingImpl concrete class. This all worked fine, even though the server log reports not finding the "class" on starup (it nonetheless AbstractFactory-instantiates the interface-based object just fine).

Ok, I know this is getting long, and the problem doesn't describe precisely, but I've tried a lot of things to get this working and am still really puzzled. If I hadn't driven through the rest of the Redbook stuff, I'd be crying right now... as it is I'm still tearing out my hair. I've even applied WSAD updates with no change in behavior.

At the very least, please tell me I'm not the only one with this tale of Redbook woe?!!!?? I haven't read about it in the forums, so am worried about working in my own private Twilight Zone (doo doo doo doo).

What am I doing wrong??? It's got to be as obvious as that damned fly buzzing into the moose's nose!!!

Thanks.
Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

Hi Guadalupe,

Why not try seeing what you get for output when you generate your client proxies and test apps from the WSDL file?

At first glance, I'd say declare it:

getInfo gi = new getInfo();
gi.CountryAbbrviation[0] = "UK";

and then call (assuming you've already loaded your proxy):

proxy.myMethod(gi);

I haven't actually tried this, so I don't know for sure if it will work. What you'll have to fool around with is the representation of the string within the object. I'm not 100% about that. The XSD declaration makes it look like it should be an array of strings instead of just one string. To make it just one string, take out the min- and max-occurs.

Again, see if you can get your code generators to build you a client testapp.

Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

Hi John,

http://localhost/myservices/myservice.asmx

will invoke the "blue banner" Service Description html page. You can use this as a human being to explore the structure of the Web Service.

http://localhost/myservices/myservice.asmx?WSDL

will invoke the actual WSDL file, which you can then supply to your proxy generation utility.

Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

This begs the real question: For the purposes of building a Web Service from a JavaBean, what's the technical definition of a JavaBean? I was under the impression that same John had, that the class had to be Serializable, which is obviously not true.

I'm working with the IBM Redbook samples, and the first one is a JavaBean-based Web Service. The class, WeatherForecast, implements no interface and extends no superclass. Every WS-published method throws 'Exception,' but other than that, there's nothing special going on.

So what elements DO you need so that a JavaBean can grow up to be a Web Service? What exceptions should it throw and are there any considerations about deployment layout (directory/jar structure)?

Keeping the answer limited to Web Service requirements...

...When is a JavaBean really a JavaBean?

Thanks.
Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

Hi All,

The biggest challenge in getting your client to go cross-platform is getting your hands on the WSDL. I just came from the other direction, trying to connect my .NET client to a Java Web Service. My biggest difficulty was trying to figure out the URL to supply for the service, which meant understanding the App Server's organizational/jar structure and puzzling out the DD's. It's much worse puzzling out .NET client/Java Web Service than Java client/.NET service.

Neither one's particularly difficult, though, once you have your hands on the URL to the service.

Once I found the URL on which to append my "?WSDL" the rest was dead easy proxy boilerplating. It should be for you too.

When you're a Java client trying to find the WSDL for the .NET service, you need to have the URL and the service ".asmx" file. With .NET, the URL is always a physical path straight to the physical ".asmx" file. There's no DD-based indirection like there is in Java.

Example:
http://localhost/myservices/myservice.asmx?WSDL

The service URL is everything up to the "?"

Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4

Hi All,

I just passed SCJP 1.4 today, with a respectable enough 77%.

Yeah, I know that 77% is not that great, but it came after only 3 days of study, 2 Whizlab practice mocks (which are definitely harder than the exam), and a two-day Java intro course about three years ago. I otherwise have zero Java experience.

So 77% looks a little better in that light. The secret in the sauce is, first and most importantly, that C# and Java are nearly identical in most fundamental regards, and that I've been a C/C++/C# programmer for twenty years now. It probably didn't hurt that the Java intro I took three years ago was with Allen Holub, who hammered anonymous inner classes, leaving me with a lasting impression of one of Java's more esoteric delights.

At any rate, I'm pleased to have the cert. I'm on my way to the ICED, because I'm tired of being locked out of good jobs just because I'm short on demonstrable J2EE experience. I figure a solid grasp of the J2EE/.NET combo and a focus on Web Services will help me to balance my portfolio.

Thanks.
Doug Hoople
MCSD.NET, MCDBA, MCSE, MCT, SCJP1.4 (freshly minted)