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

[Narasimha Reddy <simha.nry@xxxxxxxxx>]

   Sorry Guys for posting my question in inappropriate forum.

   On Fri, Oct 9, 2015 at 6:37 PM, Mike Krebs
   <[1]mkrebs@xxxxxxxxxxxxxxxxxx> wrote:

     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: [2]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   [mailto:[3]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" <[4]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:
     [5]http://www.scottklement.com/mailman/listinfo/ftpapi
     --------------------------------------------------------------------
     ---

References

   1. mailto:mkrebs@xxxxxxxxxxxxxxxxxx
   2. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   3. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   4. mailto:simha.nry@xxxxxxxxx
   5. 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
-----------------------------------------------------------------------