RE: How can I route Web Service request to different application Jobs?

[Mike Krebs <mkrebs@xxxxxxxxxxxxxxxxxx>]

Hi Narasimha,

This is the HTTPAPI message board. While there might be expertise here, Scott prefers the discussion be limited to HTTPAPI, FTPAPI and WSDL2RPG topics. The lists at Midrange.com might be a good place to ask the question. You could post in WEB400 and cross post (note the cross posting) to MIDRANGE-L and might find a better response.

Good luck.

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Narasimha Reddy
Sent: Friday, October 9, 2015 3:38 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: How can I route Web Service request to different application Jobs?

Can anyone help me on this please? Can my ideas work or any better ideas?
On Oct 2, 2015 11:15 PM, "Narasimha Reddy" <simha.nry@xxxxxxxxx> wrote:

> I have application batch jobs (listeners) running in different 
> subsystems with one sub system for each country on single iSeries 
> instance. Each country has it's own Data Base library but all of them 
> have single program library as per JobDs setup for each country. 
> Currently, these jobs run in request-response cycle using MQ. So we 
> have one MQ queue configured to each Country.
>
>
>
> Now, we are planning to switch to WebService due to many systems 
> getting requirement to access my application and many of them are not 
> interested to go on MQ. For this case, I am trying to identify a 
> routing solution. If we configure WebService as general on iSeries, 
> How can I apply the request-response cycle between Web Service Jobs 
> (HTTP Jobs?) and my application Jobs? Especially the method has to 
> serve large data buffer (1
> MB) passed thru request/response and we should handle huge traffic.
>
>
>
> Can anyone help if they have proven solutions for this scenario?
>
>
>
> I have one idea, but I am little concerned about limitations and not 
> sure if better ways available. My idea is to create Keyed Data Queues 
> (iSeries queue, not MQ)(one for each country), we will have Java 
> program running as part of WebService (QHTTPSVR or any WebService Job) 
> on iSeries WAS and that can generate unique key and put request into 
> country's queue based on county code received in request, my 
> application job driver will pick entry from queue, process it and puts 
> response back with same key value, Java can pick the entry based on 
> same key value and send response to Client. But I am worried about 
> data queue size limitations (entry can have max 64k) as I have request 
> and response buffer upto 1 MB (not always) and high volume of 
> requests. I can split each request or response into multiple entries 
> with one end tag and process. But I am unsure of efficiency, 
> performance and reliability. Does anyone know if we have to handle any critical failure situations in this approach?
>
>
>
> We could also configure different Service for each country and HTTPSVR 
> jobs configured for each country with required library list, so sever 
> job itself runs application instead of talking to another job. We are 
> not inclined to this approach due to two reasons 1) Worried about 
> COBOL being threadsafe, 2) We would like to continue to run 
> application job as decoupled for easy maintenance/debugging, load balancing etc.
>
>
>
> Please correct me or share your ideas.
>
>
>
> Thanks
>
>
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------