The most straightforward form of servlet-engine-to-servlet-engine communication is to have your first servlet invoke the remote servlet as an normal HTTP client, for example using the java.net.URL and java.net.URLConnection classes.
Frank Bennett wrote:Alan, as indicated, it seems like you are distracted by the brand names of the web servers. The quote that you posted clearly outlines the easiest way to implement communication between two servlets.
As to why you have two "identical" servlets running and want to use both of them is another design issue.
Frank Bennett wrote:It sounds like your Presentation-tier and Business-tier are tightly coupled and all jumbled together in a single server environment.
And it sounds like you want to move the Presentation-tier components, e.g. JSPs, to a different web server, possibly on a different node.
>Right, right, and right - but this abstraction is not currently intended for deployment purposes. This would be ONLY for development at the moment.
Now, you say you want trick Websphere Commerce Server into "thinking" that the Tomcat web server is it's own web server.
>That's the essential behavior I want, but really, I just want Websphere to act in "Controller" and "Model" capacity, but delegate off to Tomcat for "View"ing capacity and have Tomcat be able to understand the request from WCS as more than gibberish. I want WCS's RequestServlet to act as a secretary lol and I want Tomcat to be like "Oh, ok. You want me to serve up foo.jsp to x-forwarded-for. I can do that"
The "thinking" comment I made was merely my attempt to explain the problem
Even if you can manage to get this to work, it is an extremely questionable design and will introduce a nice chunk of associated risks.
>I'm not sure where those risks would be. This is for a new Development environment. It won't be mirrored in any other environment, let alone exposed to the outside world. Please elaborate. ...The only risk I can see arising would be having to maintain the switching of the WCS servlet from acting as a RequestServlet to an HTTPProxyServlet...but I was hoping that could be handled in configuration settings and maybe an HTTPProxyServlet adapter class that would only be deployed to the test server
A cleaner option would be to re-engineer the application so that the business logic code can be invoked remotely from any client, i.e. JSPs and servlets executing in Apache Tomcat web servers. Whether you can get IBM products to play nicely in this fashion is another discussion
>Yes, there are much cleaner options and I agree with those options as optimal. But, there's "optimal" and "I want to keep the job they just gave me" ...just trying to explain that yes I know these are tightly coupled, but I didn't couple them and I don't have an option to fully untangle the Christmas lights at the moment. It's a bit bass ackwards but I think they're in a wait and see mode on whether I can get this POC to work before they decide whether or not they're going to go on with a full-on refactor....which is what I want of course!! It'd mean stability for the foreseeable future for me
>I'll finish that thought - "You're gonna need it" lol
Frank Bennett wrote:In order to make this work, it looks like you need to be able to create your own RequestServlet instance and configure
and/or programatically get the WCS to use this instance instead of the WCS one. This will be tricky grasshopper
IBM support staff will most likely not help you with this type of effort.
>(first part) yeah...that's the trick (at least I FINALLY feel like someone out there has an understanding of what we're trying to accomplish, without regard to whether it is misguided or not....most of the replies to my posts have been academic in nature "You shouldn't do that" or "refactor refactor refactor" ...and those people obviously are independently wealthy, have their own company and make all strategic decisions for their organization lol)
>lol...we know that IBM won't help with this. IBM is a soulless, capitalistic parasite (oh...wait....I guess WE'RE soulless, capitalistic parasites too then...touché IBM...touché)
Another thing to consider: A JSP file is much more than a static HTML page. You need to also consider the Servlet Container functionality
of the web server. Typically, in an MVC implementation, there is an intimate relationship between the Controller and the View. You are attempting
to disturb this relationship, use caution.
>I believe this is spot on. It could get really messy in there...I had a short conversation with a buddy of mine and his suggestion was an RMI or CORBA solution but those are terms you read about in history class...no practical experience with that here
In regards to risks, security risks in particular, the communication between an external web server and a commerce server typically requires
strong security mechanisms. If this set-up is only intended for development, then your development environment is going to be very different
than production, QA, testing, etc. There is a risk associated with this as well in terms of possible redundant development efforts, wasted testing
cycles, etc. Ideally, your development environment should resemble production as much as possible. This type of trickery is going in the wrong direction...
Are you going to magically disable all of the security mechanisms of the application for this new development environment?
>agreed. That's why this concept is possibly off the mark. What you stated IS our goal, and to that end this concept has been devised....but we're concerned that it isn't technically possible to accomplish these tasks and meet that goal. I was thinking if we could somehow rip the WCS servlet apart to the point that it acted to service Requests but only acted as a proxy for Responses, we *might* have a shot at wiring something up. The major technical issue that I see that raised an immediate red flag is how to jump the session information from WCS to Tomcat (or Glassfish, etc, etc) and somehow provide a mapping in the "new" Servlet engine
Whole things smells like a "shot-in-the-dark" solution created by a non-technical manager trying to compensate for a poorly designed system.
>It is a shot-in-the-dark, but it's the only shot that I could see that might fit the bill for what they wanted. I knew it would be a hack job, if it could be done in the first place
Your job is to implement this, rather than convince them that there are much better strategic solutions that will work and be more
efficient in the long run. Ah, just thinking about it has given me a headache ...
>yes and no. At first glance, it's obvious that there are better strategic solutions than my proposal - but they would be more in line with long-term strategic decisions: Better workflow management, segregation of application layers, etc, etc, etc...The thing is that if I could get something like this to work, I would save the company quite a bit of money...nearly 7 figures in the department's annual budget goes to cover the seat licenses for RAD for developers who never need to use it for anything other than stupid simple jsp alterations like modifying jstl hooks.....and the RAD Eclipse plug-in locks us into a very specific implementation of Eclipse, which IBM never updates. The whole thing is a headache, but it's been in place for a long time. I'm sure that at the point that the decision was made to go with this architecture, it was a very slick solution. It's just that everyone has been in "today" mode rather than "tomorrow" mode and it finally got to the point where the size and complexity of the ecomm site has become way too cumbersome and expensive to continue this architecture long-term. They kind of asked me to step in (I'm cheap lol) and TRY to come up with a solution that could be a stop-gap while the directors have their committee meetings and budgetary meetings and we can come up with cost justification for funding to refactor the whole thing. But for some reason, (and I'll NEVER understand it) ..business people tend not to consider total cost of ownership of a solution...they just look for how costs are going to hit this year's budget.
Re-read first paragraph above for hint
In order to make this work, it looks like you need to be able to create your own RequestServlet instance and configure
and/or programatically get the WCS to use this instance instead of the WCS one.