a few observations, since i've built such systems in the past for life-sciences:
1) rest is for performing crud ops on resources, not service invocations. 2) long running computational calculations may require you submit jobs asynchronously and obtain a job/transaction id. otherwise, you lose your calc if connection is lost or client goes down. 3) scaling by adding a new box for running/deploying services sounds much more aligned with ESB approach, than a web framework. 4) moving big datasets to non-local machines for calcs can kill performance, so you can't always rely on arbitray deployment of a service - some must live on machine with resource they depend upon. 5) there are complications when services requires resource(s) exclusively. 6) lift is probably an adequate front end for what you are doing, but your backend architecture will either be ESB, GRID, or look more like a system that asynchronously accepts work and forwards it to the machine perfoming the work. either way, you'll be managing lots of stuff like resultant sets, job states, machine states, resource management, and client notification. with lift, you'll at least be able to push status of work, rather than polling if you used an older web api. On Mon, Mar 16, 2009 at 6:39 PM, parag978978 <[email protected]> wrote: > > Hi David, > > Thanks for the feedback. The goal I am trying to accomplish to create > a web service framework written in scala that uses a rest api to > communicate to the outside world. This web services framework would > be the deployer for pojos/scala applications. It only reason for > being is to process requests and return them. Now web services that > could be created could be very processor intensive. The web services > themselves might be communicating with a mulitude of web apps / > applications that need its services. > > To be more specific these web services sits in the domain of > healthcare. > > So I am trying to implement the web services framework in the stack > below > > --------------------------------------------------------------- > Applications - Electronic Medical Records, Patient Health Monitor, > etcs > > Applications Frameworks - Ruby on Rail, Django, J2EE, Lift...etc > > ___________________________________ > > web services framework - can easily deploy new web services, rest api > for communication with outside, very scalable, scaling is just as > easy as adding a new server. automates deployment, scaling, and load- > balancing. > > Web services are just pojo and scala classes. > > Uses Scala Actors and manages the actors similarly to Erlang OTP. Has > properties for being fault tolerant (server dies no problem mon, > another one takes it place right away). Needs to handle large number > concurrent users since > #concurrent_sessions = sum(applications(i)+users(i)). > > _________________________________________ > > The DB it uses will be some sort of key/value or key/value/document db > that is already an open source project like couchdb. > > > So initially I thought of using Lift so it might already have some of > the things, but now I feel that it might need to be done from scratch, > unless you know any other open source framework that has the qualities > I described. > > Thanks > > Parag > > > > > On Mar 16, 12:54 pm, David Pollak <[email protected]> > wrote: > > On Sun, Mar 15, 2009 at 6:34 PM, parag978978 <[email protected]> > wrote: > > > > > I want to know the technical reasons why the lift webframework has > > > high performance and scalability? > > > > The JVM and not getting in its way. :-) > > > > The JVM is the best way to deploy high performance software. HotSpot > does a > > better job of optimizing code than any static compiler and GC-based > memory > > management is faster in aggregate than malloc/free. Yes, folks can find > > micro-benchmarks that demonstrate that C programs are faster, but those > > examples don't scale as the complexity of the systems grow. > > > > Scala's immutable data structures make scaling apps much easier. > > > > > I know it uses scala, which has an > > > actor library, but according to the install instructions it default > > > configuration is with jetty. So does it use the actor library to > > > scale? > > > > Actors and Jetty have nothing to do with each other. Lift takes > advantage > > of Jetty and Servlet 3.0 continuations for long polling operations. Lift > > also use Actors for long polling so there are no threads consumed during > the > > polling. > > > > > > > > > Now is the scalability built right out of the box. Just add additional > > > servers and nodes and it will automatically scale, is that how it > > > works? Can t handle 500000+ concurrent connections with supporting > > > servers. > > > > Can you elaborate on this goal. There's no enterprise system that I know > of > > that has this kind of requirement. Most enterprise systems need no > support > > more than a few thousand open sessions. Even the largest companies don't > > have more than a few thousand people accessing the same app. > > > > Thanks, > > > > David > > > > > > > > > I am trying to create a web services framework for the enterprise > > > level, that can beat what is out there and is easy to scale, > > > configurable, and maintainable. My definition of scaling is just > > > adding more servers and you should be able to accommodate the extra > > > load. > > > > > Thanks > > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > Follow me:http://twitter.com/dpp > > Git some:http://github.com/dpp > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
