Hey Nathan
My experience with IWS is on the server side, providing a web service.
IWS server side one and only function is to expose an ILE program or
service program as a web service. Nothing else.
Most of the tooling is hidden. You provide the wizard with
- a program to expose
- PCML which describes the entry point(s) and parameters
- mark parameters as input, output or input/output.
- the library list
Bang that's it, you have a web service.
The point is to make exposing an ILE program or service program simple
for the non-Java / web programmer.
IBM is responsible for all the Java code, beans and goodies. You
shouldn't touch them (of course I had to find out how the stuff is
stored but that is another story).
It is a matter of preference. In our shop I am the only one who knows
much about Java. This lets us provide ILE service programs that our
customers can call as web services. We don't have to worry about the
plumbing.
Yes, you are out of luck if you have to / want to tweak the Java code.
No, with IWS you can't do anything with the parameters coming from the
SOAP bundle into the ILE program or coming from the ILE program into the
SOAP bundle.
On the other hand
- deployment is simplified
- IWS requires less resources to run (good if your System i can't afford
the overhead of Websphere). Less resources are required because IWS
does less and because it uses the 32bit JVM.
- it is part of the operating system (V5R4 and above).
It is a turn key solution.
I have found it to be very solid within the domain it addresses. Don't
even try to make it work outside that domain. If you need features /
capabilities of web services which IWS doesn't address definitely use
something else.
As for how we use it, we are providing support for our customer's IVR.
The IVR calls the web service to make an inquiry, that goes to the RPG
service program, the service program answers, the results are returned
in parameters which the web service returns to the customer.
If the customer were using a System I they could call the service
program. They don't but with IWS they can call the service program
through web services.
I hope IBM will improve IWS. My frustration with it is that the WSDL is
dynamically generated. You can't (easily) improve it. You can't add
documentation to it. You can't add parameter validation to it.
Oh well.
I think it is a pretty good solution for a very specific problem.
Bill Blalock
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Nathan Andelin
Sent: Monday, September 22, 2008 2:28 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] RPG as Web service
From: "Blalock, Bill"
All the Java code and XML is generated by the wizard, you
never see it.
Hmmm, until you need to debug it...
I've been following this discussion, which is split across this list and
Midrange-L, and I don't quite understand IBM's positioning of IWS, vs
tooling in WDSC, vs tooling in RDi, for web services, except that
they're all Java based, and provide mechanisms for calling RPG programs
and procedures.
I read Shannon O'Donnell's article in IT Jungle, for example, which
described the tooling in WDSC for generating and testing web service
servlets, pcml, and program call beans, which make calls to RPG programs
and procedures. The tooling will even generate EAR files, for
deployment to WAS.
It would be helpful if you could describe your experience with IWS.
What type of web services you're deploying, for example.
Thanks,
Nathan.
midrange.com
