Re: Socket Tutorial and HTTPAPI

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Why do you want to write your own server for this?  i5/OS comes with a 
really good HTTP server, which is fully capable of utilizing RPG 
programs.  Why would you want to write your own?

If you DO decide to write your own, please take a look at the following 
articles which show newer, better ways of creating servers than the old 
stuff on my web site:

http://systeminetwork.com/article/easier-way-write-tcpip-server-program
http://systeminetwork.com/article/tcpip-handoff-server

Plus, here's an article about timing out sockets that has little to do 
with what you asked, but I have a feeling that it'll be of interest to you:
http://systeminetwork.com/article/timeouts-sockets-0


But, again, I wouldn't write my own server for this.  I'd use Apache in 
i5/OS, and I'd just configure it to call an RPG program.  For a REST web 
service, CGIDEV2 would pretty much do all of the work for you.   For a 
SOAP web service, you'd probably have you write your own WSDL (with the 
help of a tool like SoapUI) but then have the RPG program use an XML 
parser (either the XML-INTO/XML-SAX opcodes, or Expat, or even take 
advantage of the simplified Expat wrappers in HTTPAPI if you like.)

HTTPAPI is not really apropos to PROVIDING a web service.  It's purpose 
is to CALL ("Consume") a web service -- though technically, HTTPAPI 
doesn't know anything about web services, it just knows about HTTP 
communications and XML parsing, both of which are useful in web services.

Thomas Raddatz's WSDL2RPG is a tool that knows a lot more about web 
services (it uses HTTPAPI for parts of the work, under the covers). So 
it can do more of the work for you -- again, only if you're planning to 
CONSUME web services, it's not designed (AFIAK) for providing them.

Also, IBM provides a tool called "WebSphere" that runs on i5/OS, and it 
has tons of web services capabilities.  The WDSC tool is capable of 
generating Java wrappers for RPG programs so that you can use WebSphere 
(which is a Java tool) as a front-end for RPG web services... that's 
probably the simplest option you have available.

Also, there are tons and tons of vendors selling tools for this sort of 
thing. (Indeed, I'm currently at COMMON and it's really hard to walk 
around without accidentally tripping over another vendor selling some 
webservices or SOA thing -- though interestingly, very few of them seem 
to know what SOA actually means.)

As for the rdline() routine...  I wrote that for the socket tutorial, 
but I don't use it in production code.  It's intended to be simple to 
help you understand the concepts... it's not intended to perform well or 
be robust.


Donald Leong wrote:
>    Hi Scott,
> 
>    I am working on a SOA project and came across this wealth of
>    information. I downloaded both the Socket Tutorial and HTTPAPI from
>    your site and am playing with those codes. My aim is to make my i5 to
>    participate in the companywide SOA bandwagon. My thinking is to build
>    a "listener that spawns multiple programs" based on the samples from
>    the socket tutorial. Once client requests are processed, the result
>    will be encased in a SOAP-based XML for sending back to client using
>    HTTPAPI.
> 
> 
>    Based on this assumption I have a couple of questions:
>     1. Is this the right approach? Or can HTTPAPI do both inbound and
>        outbound traffic (I see most of the examples on HTTPAPI are i5 as
>        a consumer but not as a provider)?
>     2. Is the function RDLINE in the SOCKUTIL_H copy book to accept an
>        XML document by manipulating the length from peLine?
> 
> 
> 
>    Thanks,
> 
>    Donald Leong
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------