Connecting Apache's Web Server to Multiple Instances of Tomcat
http://www.linuxjournal.com/node/8561/print
Monday, January 16, 2006
Thursday, January 12, 2006
Wednesday, January 11, 2006
Voice Application with J2EE
I'm convinced that J2EE lightweight container architecture is the right way to go for the majority of voice applications. However, there needs to be some tweaks in the way the UI tier utilizes it, compared to what we're used to seeing with HTML-based applications.
The standard platform architecture for Voice Application is to have 100 or so browser instances sitting on a server. The browser is not located on the client, because the client is a POT (Plain Old Telephone). The caller dials up a computer with a Dialogic or NMS card, or a SIP gateway, and the call is routed to one of the browser instances running on a server. This may be the same server that's running the app server, or it may just be on the same LAN.
So now the browser cache becomes much, much more important. If I have a few thousand phone calls coming in every hour to those 100 browsers, and they're all running the same application, the absolute worst thing I can do is a lot of dynamic page rendering. That would involve parsing the JSP into VoiceXML, and parsing the VoiceXML into runnable code, on every request.
So, component libraries like Tapestry or JSF are out. MVC frameworks like struts could be okay, as long as they're redirecting to static VoiceXML pages, instead of forwarding to JSPs.
The standard platform architecture for Voice Application is to have 100 or so browser instances sitting on a server. The browser is not located on the client, because the client is a POT (Plain Old Telephone). The caller dials up a computer with a Dialogic or NMS card, or a SIP gateway, and the call is routed to one of the browser instances running on a server. This may be the same server that's running the app server, or it may just be on the same LAN.
So now the browser cache becomes much, much more important. If I have a few thousand phone calls coming in every hour to those 100 browsers, and they're all running the same application, the absolute worst thing I can do is a lot of dynamic page rendering. That would involve parsing the JSP into VoiceXML, and parsing the VoiceXML into runnable code, on every request.
So, component libraries like Tapestry or JSF are out. MVC frameworks like struts could be okay, as long as they're redirecting to static VoiceXML pages, instead of forwarding to JSPs.
Reusable Dialog Component (RDC) for voice application
A Reusable Dialog Component (RDC) is basically a JSP 2.0 tag, which generates VoiceXML at runtime. RDCs are part of the RDC Tag Library open source Jakarta project. Version 1.0 of the RDC Taglib was released in July 2005. The RDC Taglib projects implifies the development of server-side code in order to generate Voice XML. The RDC Taglib project includes a set of RDCs, which are a collection of JSP 2.0 tags that assist in the development of Voice applications. The RDC tags generate VoiceXML at runtime, which can execute on any VoiceXML 2.0 compliant platform. The RDC Taglib also provides a framework for implementing additional RDCs. The framework helps in orchestrating each individual RDC making sure the user data is collected, verified, and canonicalized. The collection of RDCs included in the Taglib project is made up of both, atomic and composite RDCs. Atomic RDCs collect a single piece of information from the user. For example, date, time, or zipCode are atomic RDCs. Composite RDCs collect multiple pieces of information from a user. These are usually done by using atomic RDCs or aggregating a composite with other atomic RDCs.
Subscribe to:
Posts (Atom)