from where I am sitting, sounds like the project doesn't have enough information to make a good decision. Why move from MML/TCP to VXML/HTTP?
if you read my performance article on the resources page, XML is very CPU and memory intensive. Even with XStream java-xml binding library, handling moderate concurrent load will easily consume 100% of the CPU. if you're serious about using VXML/HTTP, you're going to have to use some kind of hardware acceleration to get wire speed. even without implementing a single line of code, I can tell you right now it is going to be really hard scaling VXML/HTTP to handle 50 concurrent streams. On a 3ghz cpu, 30 concurrent stream will consume 100% of the CPU. With a 2.4ghz CPU, 10-15 concurrent xml parsers will consume 60-75% of the CPU regardless of the platform. it doesn't matter if you write it in C#, C++, C or Java. I keep a pretty close watch on XML technology and most of the parsers today are about the same. the differences are not significant to me. given the primary limitation is CPU consumption, your options for application server should be based on reliability, maturity and toolset. If J2EE provides the features and scalability you need, then use it. If writing your own application server in C++ is the best option, then find two guys who have 10 years of experience writing high performance app servers. I would guess using servlets/jsp is the least of your concerns at this point. Until you have the VXML driver written and know it's performance characteristics, any decision on app server will be premature. You may want to look at Xml Pull Parser3, XStream, Jixb, XBis and the new xml stream parser. do a quick implementation for VXML and see what kind of performance you get. if that is sufficient, you can move on. otherwise, you may have to write a highly optimized VXML parser in C using a finite state machine of some sort. good luck peter On Thu, 8 Jul 2004 18:19:23 -0700, Darshan Rawal <[EMAIL PROTECTED]> wrote: > We implement a Messaging PLatform for Voice Applications. > Our current platform has 2 Major Components as shown below:- > > Media Server <--- MML/TCP-IP ---> Application Server. > > We want to move to a new architecture for our Application Server where > the interaction between App Server and Media Server is as shown > below(i.e. based on VXML over HTTP) > > Media Server <--- VXML/HTTP ---> Application Server. > > To achieve this goal we need to implement an "VXML Document Server", > which will generate VXML > (Voice XML) pages based on the business logic & Data access layers > within the Application server. > > We have 2 options to implement the VXML document Server:- > > 1) USing the J2EE presentation tier(i.e. JSP & Servlets) > 2) Writing our own VXML generation module in C++ based(probably based > on the JAVA Servlet paradigm). > > Our Factors while deciding between the 2 would be as follows:- > > 1) Performance(This is the key for us, we ezpecially need to know > exactly how slow JAVA is as Compared to C++) > 2) Integration with our Business logic & Data Access Layers.(All our > business logic & data access is written in C/C++. Hence if we chose > JAVA, then we might have to use JNI or make use of TCP/IP to > communicate with our different Processes written in C/C++) > 3) Ease of Future Change(We want to develop new Application Features > Quickly & fast). > 4) Fast & better Development environment. > > I am a proponent of the use of Tomcat Servlet Container and hence the > use of J2EE front end for our module. But I was hoping to get some > pointers from you all, just in case somebody might have implemented > something similiar or might just have some inputs nevertheless. > > We are in a time crunch here, as we have to make a decision by next Monday end. > > Thanks in advance. > > Regards, > > Darshan. > > --------------------------------------------------------------------- > 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]
