You may want to look @ Jigsaw which is HTTP server that can be configured as a HTTP Client (by implementing it as a Proxy). I did this like 5-6 years ago and it served my purpose very well.
The HTTP Client would generate the HTTP requests to the web server(s). The response would get cached to disk and processed/transformed to the business logic layer via a client side filter mechanism that Jigsaw has. Should save you from writing a lot of code.. A classic case for the Adapter pattern. Jigsaw is at: http://www.w3.org/Jigsaw/ Mahesh ------------------------------------------ Mahesh Joshi W- 408-543-7214 M- 408-829-8051 [EMAIL PROTECTED] >>-----Original Message----- >>From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >>Sent: Thursday, October 16, 2003 4:56 PM >>To: Struts Users Mailing List >>Subject: RE: [Semi OT] When does a servlet get a session? >> >> >>Funny you should suggest that. We're currently considering >>this as an option. >> >>The DF1 protocol is a stone-age protocol used by >>Allen-Bradley Programmable Logic Controllers and as such is >>very inflexible. >> >>While we work on this, we're gonna work with our load >>balancer and try to get our sessions to be extra-sticky so >>that the likelyhood of two different requests from a PLC >>going to different WAS servers is greatly reduced. It >>certainly is a pickle of a situation! >> >>Simon >> >>>-----Original Message----- >>>From: Joseph Fifield [mailto:[EMAIL PROTECTED] >>>Sent: Thursday, October 16, 2003 6:06 PM >>>To: Struts Users Mailing List >>>Subject: Re: [Semi OT] When does a servlet get a session? >>> >>> >>>I suppose you could fake the http requests yourself, couldn't >>>you? When the >>>DF1 request comes in, translate it to an http get or post >>>request and send >>>it off to your existing struts system. Translate the http >>response into >>>whatever is needed for the DF1 response. >>> >>>Also, does this DF1 protocol have any notion of a session? In >>>other words, >>>is there some unique identifier sent with each request to tie >>>it to other >>>requests, or are all requests basically global? Either way, >>>you would need >>>to send an appropriate jsessionid value back with your fake >>>http requests in >>>order to maintain the same http session. >>> >>>Joe >>> >>>----- Original Message ----- >>>From: "Chappell, Simon P" <[EMAIL PROTECTED]> >>>To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >>>Sent: Thursday, October 16, 2003 5:31 PM >>>Subject: RE: [Semi OT] When does a servlet get a session? >>> >>> >>>Craig, >>> >>>>-----Original Message----- >>>>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] >>>>Sent: Thursday, October 16, 2003 4:19 PM >>>>To: Struts Users Mailing List >>>>Subject: Re: [Semi OT] When does a servlet get a session? >>>> >>>> >>>>Chappell, Simon P wrote: >>>> >>>>>You're right that we'll never have an HTTP request, so I can >>>>see why you're confused as to why we'd want a session. The >>>>reason is for performance. We want to avoid the overhead of >>>>writing and reading a database. This is very short term >>>>information, but now that we're needing to run in a >>>>load-balanced cluster, we need to be able to handle the >>>>situation where requests could, in the worst case scenario, >>>>come into each server alternatively. IBM's WebSphere App. >>>>Server when running in a cluster will propogate the session to >>>>any server that needs it. Thus if we use a session, it'll >>>>propogate back and forth between the boxes. >>>>> >>>>> >>>>The problem you're going to have is that there is no such >>thing as an >>>>HttpSession without an HTTP request. >>> >>>We found that out! :-( >>> >>>>Even if you could do what you >>>>propose, it would only make the stored information available >>>>to a single >>>>user -- that doesn't seem like it will do what you want. >>> >>>Actually, it is exactly what we want. This servlet only exists >>>to start our >>>socket listener. This is a "certifiably awful hack", but they >>>wouldn't let >>>us run a separate server application, so when all you have >>is a servlet >>>engine, everything looks like a hammer (or something like that). >>> >>>>A possible strategy to avoid READING the database on every >>>>request is to >>>>have a webapp startup method load the data into a servlet context >>>>attribute. This will happen on each node the app is >>deployed to, but >>>>will happen only once (before the first request is processed). >>> >>>Actually, we have something like that now, where we store >>>information in a >>>static variable in the servlet. That works fine. The issue is >>>that for WAS >>>to replicate it between server instances, it needs to be in >>the servlet >>>session that we don't have. >>> >>>The other challenge is that we don't have any control over the >>>DF1 protocol >>>or the serial to IP device that calls our listener. We asked >>>our engineers >>>if they could try faking some HTTP and then we could send the traffic >>>through our existing Struts based system, but it would seem >>that is not >>>possible with the current hardware situation that they work with. >>> >>>Simon >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
