Thanks Joe, yeah - we can use HTTP. Was just trying to make sure that I wasn't overlooking a simpler, more standardized method of building webapps for use within a larger site.
cheers, chas >Well if the folks can actually write servlets (or even other simpler things) >then there certainly are options. > >a) First, they could send you some XML over some HTTP post operation. Doing >a post operation is simple and creating XML is simple. You then return what >you wish ... easiest is probably more XML since parsers are all over the >place. Essentially that is what SOAP and XMLRPC do, except they are very >well structured on what they look like (and have extra associated overhead >of learning a standard). > >b) You can do a simple form post (either via GET or POST), one name value >pair can represent the 'function' and the other name value pairs can >represent the 'parameters' to the function and you return the 'value' as you >see fit (in any format you wish ... again XML is probably easiest due to >parsers, etc). > >Both of these can be done (by your users) in JSP, Servlets, ASP, Perl, etc. >They are both fairly simple, but they are conceptually the same as SOAP and >XMLRPC, you are using HTTP to perform an operation. Before the SOAP and >XMLRPC standards I used the a) approach quite often when it came to simple >non-speed oriented systems, otherwise I used RMI on Java and either DCE or >ONC RPC on C++ systems. > > >---------------------------------------- >Joseph Molnar >http://www.codesta.com/ > >----- Original Message ----- >From: "chas" <[EMAIL PROTECTED]> >To: "Tomcat Users List" <[EMAIL PROTECTED]> >Sent: Saturday, April 06, 2002 12:29 PM >Subject: Re: inter-webapp communications > > >> Thanks for the speedy response, Joseph. >> >> At 18:47 05/04/2002 -0800, Joseph Molnar wrote: >> >Generally people are using SOAP or XMLRPC or some other mechanism that >would >> >constitute being a 'web service'. >> >> Was hoping to avoid SOAP or XMLRPC - they're a bit >> beyond the end-developers who'll use my webapp and >> it's just that added barrier to entry. >> >> Really, would love for them to be able to integrate >> my webapp into their own website with no further >> experience other than the ability to write a servlet >> (which I know they can). >> >> Have just realized that RequestDispatcher won't cut >> it either - because it relies on the called servlet >> being within the same context (/...) which isn't the >> case with a separate webapp. >> >> Taglibs are certainly looking like the cleanest >> mechanism now... but I dislike JSPs myself. >> >> still searching. >> >> thanks again, >> >> chas >> >> >> >> >> >> >----- Original Message ----- >> >From: "chas" <[EMAIL PROTECTED]> >> >To: <[EMAIL PROTECTED]> >> >Sent: Saturday, April 06, 2002 10:24 AM >> >Subject: inter-webapp communications - anything better than >> >RequestDispatcher? >> > >> > >> >> Is there any standard mechanism for inter-webapp communication ? >> >> >> >> Perhaps an example would explain this better: >> >> >> >> On my production server, our website is in ><tomcat_home>/webapps/mainsite >> >> This contains content, forms, JSPs, servlets, the standard corporate >> >website. >> >> >> >> Now, on my laptop I've created a standalone webapp for an events >calendar, >> >> and another webapp that is a discussion forum. >> >> <tomcat_home>/webapps/eventscal >> >> <tomcat_home>/webapps/forum >> >> >> >> Of course, I can deploy these 2 webapps on the production server but >> >> do not wish them to be independent sites. Instead, I wish to make >> >> calls to these from the main website - treating them as individual >> >> components. For example, a servlet or JSP in my main site might >> >> call (pseudocode) - eventscal.addEvent() or forum.addDisplayThread() >> >> >> >> Is there a standard mechanism for this ? >> >> >> >> >> >> Options I've considered : >> >> >> >> a. Creating a custom taglib. Don't wish to do this because I wish >> >> to be free of JSPs. Also, I still want to be able to deploy the >> >> webapp as a standalone application if needs be. >> >> >> >> b. I could do this with RMI but that seems like overkill and slower >> >> performance. However, it has the advantage that it's scalable (if >> >> ever I had to deploy over multiple machines). >> >> >> >> c. RequestDispatcher is the closest that I've seen and I'm happy >> >> to continue using this unless there is a better way to do it. >> >> >> >> Really, I'm looking at the best mechanism for packaging a >> >> webapp so that other people can use it as part of their >> >> existing site. eg. one that is perhaps more J2EE or framework >> >> friendly, so that the webapp can be used by a greater number >> >> of people. If I'm going about this completely wrong, pls do say. >> >> >> >> Thank you very much for bearing with me, >> >> >> >> chas >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> To unsubscribe: <mailto:[EMAIL PROTECTED]> >> >> For additional commands: <mailto:[EMAIL PROTECTED]> >> >> Troubles with the list: <mailto:[EMAIL PROTECTED]> >> >> >> >> >> > >> >-- >> >To unsubscribe: <mailto:[EMAIL PROTECTED]> >> >For additional commands: <mailto:[EMAIL PROTECTED]> >> >Troubles with the list: <mailto:[EMAIL PROTECTED]> >> > >> > >> > >> >> -- >> To unsubscribe: <mailto:[EMAIL PROTECTED]> >> For additional commands: <mailto:[EMAIL PROTECTED]> >> Troubles with the list: <mailto:[EMAIL PROTECTED]> >> >> > >-- >To unsubscribe: <mailto:[EMAIL PROTECTED]> >For additional commands: <mailto:[EMAIL PROTECTED]> >Troubles with the list: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
