an approximate figure would be the number of persons querying the systems to see the progress of their cases, some dating back in the 80s to date. people in this case is a combination of the general public, lawyers, court staff. i'm insisting on the platform because previous attempts on the project using PHP has borne no fruit, though this has more to do with the design on which the system was developed. The initial developer did not put much into consideration when building up the system such that scalability is highly constrained. in which case i prefer starting all over than trying to fix bugs that never end. On Tue, Sep 1, 2009 at 2:24 PM, Peter Karunyu <pkarunyu@gmail.com> wrote:

When you say "*volume of transactions of this magnitude*", can you put it into approximate figures? One thousand, one hundred thousand, one million, several hundred millions concurrent requests? You mentioned that it is a court registry system, how large can the user base be?

In my opinion, there is a larger pool of knowledge, scripts, libraries, frameworks etc when it comes to PHP than JSP.

Remember, the prowess of the person writing the PHP or JSP can make or break the system, regardless of how ideal the chosen language is. How good are your developers in either of those two languages?

On Tue, Sep 1, 2009 at 12:02 PM, Benjamin Kilonzo <b_kojoe@yahoo.com>wrote:

...

Well Obunga i think you answered your own question already.

I would highly recommend using Java Servlets & Java Beans which would do the trick to implement the scenario you describe. Servlets & Beans provide extensibility and the necessary functionality that can be "extended " and released bit by bit as the system continues to be used.

PHP is an excellent web language though i don't think it provides enough or thorough "component" based architecture to enable you create an application of the magnitude described.The volumes of transactions being a consideration and am sure you don't want to keep debugging as a result of heavy traffic java still rules. As for the timeframe being limited you may contact me off list and we see how i may be able to help with "some" of the components.

Regards, BK.

--- On *Tue, 9/1/09, Ogure Obunga <write2ogush@gmail.com>* wrote:

From: Ogure Obunga <write2ogush@gmail.com> Subject: [Skunkworks] PHP vs Servlets/JSP To: skunkworks@lists.my.co.ke Date: Tuesday, September 1, 2009, 8:35 AM

Hi good people,

I'm torn between a choice of platform based on the underlying application. I would like to implement a system for the court registry. Among other things, the system should be self updating at the point on which data is entered, the result of which is sent to the web interface for the public. There are several categories of users with different levels of access. Its an online based system.

PHP comes in handy though I tend to think Servlets have the power to handle the volume of transactions of this magnitude especially by the fact that it combines both a stand alone system that feeds the web-based interface, save for the complexity that comes with it. The time frame for development is limited.

Your take(s)?

Regards

Obunga Ouya 0720 438 527

-----Inline Attachment Follows-----

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke<http://mc/compose?to=Skunkworks@lists.my.co.ke> http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science: http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi: http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science: http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi: http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general

I don't think the technology is the problem. You will need to answer 1. Is the team doing the design good? 2. Is the design good (does it cater for concurrency, contention, redundancy, high load etc) 3. Is the team doing the development good, organized and able to work as a team? 4. Is there a project manager and a team lead? 5. In light of the above is the remaining time realistic to do the work? If the answer to any of these is no then it won't matter what language you use -- you're in trouble either way. On Tue, Sep 1, 2009 at 3:08 PM, Glenn Sequeira <gsequeira@gmail.com> wrote:

On Tue, Sep 1, 2009 at 2:47 PM, Ogure Obunga<write2ogush@gmail.com> wrote:

...

an approximate figure would be the number of persons querying the systems to see the progress of their cases, some dating back in the 80s to date. people in this case is a combination of the general public, lawyers, court staff.

I don't think you'll have a problem with PHP per se.

From a presentation by Cal Hendersen (developer of Flickr which is a PHP application) [http://www.niallkennedy.com/blog/uploads/flickr_php.pdf], back in 2004 they were handling:

~25,000 DB transactions/second at peak ~1000 pages per second at peak

On a slightly related note, John Adams gave a great presentation at the Velocity 2009 on the challenges of scaling a site (Twitter) to serve millions of users. [http://en.oreilly.com/velocity2009/public/schedule/detail/7479]

From your project description, and at the risk of being buried in an avalanche of skunks criticisms, I'd say: forget the over-engineering, start simple. Scale issues can be fixed later, if that will ever be necessary. And take advantage of feedback-loops from users by releasing early and often. All this is community wisdom:

1. Release early and release often : http://www.paulgraham.com/startuplessons.html 2. Simplicity is the most important consideration in a design. : http://www.jwz.org/doc/worse-is-better.html 3. Scale, generality or completeness are NOT unqualified virtues: http://www.shirky.com/writings/situated_software.html saidi On Tue, Sep 1, 2009 at 12:18 PM, wesley kirinya <kiriinya2000@yahoo.com>wrote:

Ogure, Dude,

After reading your reasons:

1. It seems like this system will be large. I suggest making sure the Requirements, Architecture and Design are well in place, even before choosing the programming language. Infact with the above in place, choosing the language is simple as all you have to look at are the pros and cons of each.

2. For what it's worth: I recommend servlet/java. Your main issue with this system will be implementing 'Business Logic', unlike systems like Flickr or Twitter. PhP is not typesafe nor is it object oriented. O_O

--- On *Tue, 9/1/09, Rad! <conradakunga@gmail.com>* wrote:

From: Rad! <conradakunga@gmail.com> Subject: Re: [Skunkworks] PHP vs Servlets/JSP To: "Skunkworks forum" <skunkworks@lists.my.co.ke>, write2ogush@gmail.com Date: Tuesday, September 1, 2009, 3:20 PM

I don't think the technology is the problem. You will need to answer

1. Is the team doing the design good? 2. Is the design good (does it cater for concurrency, contention, redundancy, high load etc) 3. Is the team doing the development good, organized and able to work as a team? 4. Is there a project manager and a team lead? 5. In light of the above is the remaining time realistic to do the work?

If the answer to any of these is no then it won't matter what language you use -- you're in trouble either way.

Ooopps sorry for that. Php5 has OOP.   8~|   --- On Tue, 9/1/09, Dennis Kioko <dmbuvi@gmail.com> wrote: From: Dennis Kioko <dmbuvi@gmail.com> Subject: Re: [Skunkworks] PHP vs Servlets/JSP To: "Skunkworks forum" <skunkworks@lists.my.co.ke> Date: Tuesday, September 1, 2009, 8:34 PM what happened to object oriented php? who killed it? On 01/09/2009, saidimu apale <saidimu@gmail.com> wrote:

From your project description, and at the risk of being buried in an avalanche of skunks criticisms, I'd say: forget the over-engineering, start simple. Scale issues can be fixed later, if that will ever be necessary. And take advantage of feedback-loops from users by releasing early and often. All this is community wisdom:

    1. Release early and release often :     http://www.paulgraham.com/startuplessons.html     2. Simplicity is the most important consideration in a design. :     http://www.jwz.org/doc/worse-is-better.html     3. Scale, generality or completeness are NOT unqualified virtues:     http://www.shirky.com/writings/situated_software.html

saidi

On Tue, Sep 1, 2009 at 12:18 PM, wesley kirinya <kiriinya2000@yahoo.com>wrote:

...

Ogure, Dude,

After reading your reasons:

1. It seems like this system will be large. I suggest making sure the Requirements, Architecture and Design are well in place, even before choosing the programming language. Infact with the above in place, choosing the language is simple as all you have to look at are the pros and cons of each.

2. For what it's worth: I recommend servlet/java. Your main issue with this system will be implementing 'Business Logic', unlike systems like Flickr or Twitter. PhP is not typesafe nor is it object oriented.   O_O

--- On *Tue, 9/1/09, Rad! <conradakunga@gmail.com>* wrote:

From: Rad! <conradakunga@gmail.com> Subject: Re: [Skunkworks] PHP vs Servlets/JSP To: "Skunkworks forum" <skunkworks@lists.my.co.ke>, write2ogush@gmail.com Date: Tuesday, September 1, 2009, 3:20 PM

I don't think the technology is the problem. You will need to answer

    1. Is the team doing the design good?     2. Is the design good (does it cater for concurrency, contention,     redundancy, high load etc)     3. Is the team doing the development good, organized and able to work     as a team?     4. Is there a project manager and a team lead?     5. In light of the above is the remaining time realistic to do the     work?

If the answer to any of these is no then it won't matter what language you use -- you're in trouble either way.

-- with Regards: Kazi kwa vijana and other idiots,  all at my blog: http://gramware.blogspot.com _______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science:  http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi:     http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general

Hi Skunks and Nicholas, I highly disagree with you that PHP does not scale as well as JSP/Servlets - I will even go as far as to say that it scales better. That PHP does not scale / is enterprise ready is an old myth, one that most likely is a result of the fact that very few PHP applications are engineered with scalability in mind, or is just of poor engineering quality. Prime examples of PHP applications that scale very very well are Wikipedia & Facebook. The main difference is that PHP is stateless and JSP/Servlets is statefull. This leads to the fact that PHP applications (usually) is very easy to scale across multiple servers (i.e. scale very high) whereas JSP/Servlets (usually) is able to scale better when running on a single server - but often have a hard time running on multiple servers without considerable extra engineering. however bad design/engineering can ruin any chance of an application scaling - both with Java & PHP. Regards Michael Pedersen PLUSPEOPLE Nicholas Loki wrote:

Hi Skunks, Allow me to disagree with what comrade Saidi mentioned about over-engineering. I think in any enterprise system design a high degree of over-engineering is expected. Personally I would go with start simple but make sure your simple anticipates and expects features that may come up in later releases. About the language of choice, if you want fast turn around times for your development cycles together with ease of use PHP is the way to go. Though I still think it doesn't scale well under increased load. JSPs/Servlets scale very well under load, but are more complex to develop and maintain. Either way you need skills to achieve productivity with both approaches.

Another way to look at it is, you could use a hybrid approach and have PHP for the front end and JSP/Servlets for business logic etc in the back end. You could then use REST APIs or WebServices to pass messages back and forth within the architecture. A bit of an overkill, but might be the way to go with really high volume systems.

KR, Loki

Hi Nicholas & other Skunks, We are saying the same thing ;-) You just explained the difference between the stateless and statefull models. I agree with you that Java on a J2EE server has the potential to scale better than a "normal" PHP application when restricted to one server - however the way you have to code the java app in order to achieve this, is usually the exact techniques that prevent that Java app from using the power of multiple servers. Said in another way: Java scales best on one server - but once you reach the limit of whatever that application is able to do on that one server, you most likely have to rebuild large part of your application to make it scale even higher. (and it is not as if PHP does not scale on one server - it does, just not as good as java) When you then factor in the cost of application development & testing with the ever falling price of hardware, everything is in favor of being able to utilize multiple servers. Prime example is Google - there datacenters are build with the equipment that gives the most processing-power/dollar i.e. many many "normal" servers instead of one "big" one. Finally you _can_ code PHP in a statefull way - if you use e.g. memcache (its just not the default way) - the end result is that the way you structure your application can be exactly the same as when building a J2EE application - and if you really want then you can also code a java application in a stateless way (but there is little point in doing this). All in all - I would say that if you use Java or PHP (or something else) - it does not matter - let personal preference rule depending of the nature of the project naturally. Regards Michael Nicholas Loki wrote:

Hi Michael, I agree with you on two points. First that PHP can scale well across multiple servers and secondly that bad design/ engineering can ruin any chance of an application scaling whether it be developed in Java or PHP. I think scaling in this case has to be defined and metrics put in place for it to make sense. On a single server with high processing power PHP fails in scaling by virtue of the fact that it runs as an add on module on a Web Servers. JSP/Servlets on the other will run in a Web Container or J2EE server which in turn runs in a JVM. With increased processing power on a single server you can increase the instances of your Web Container/ J2EE server to scale the system. Again scalability has to be defined and metrics put in place for it to make sense. I still think that Java scales better than PHP even on a single server.

KR, Loki

"Excellent people exceed expectations".

------------------------------------------------------------------------ *From:* Michael Pedersen <sku@kaal.dk> *To:* Skunkworks forum <skunkworks@lists.my.co.ke> *Sent:* Wednesday, September 2, 2009 11:22:50 AM *Subject:* Re: [Skunkworks] PHP vs Servlets/JSP

Hi Skunks and Nicholas,

I highly disagree with you that PHP does not scale as well as JSP/Servlets - I will even go as far as to say that it scales better. That PHP does not scale / is enterprise ready is an old myth, one that most likely is a result of the fact that very few PHP applications are engineered with scalability in mind, or is just of poor engineering quality. Prime examples of PHP applications that scale very very well are Wikipedia & Facebook.

The main difference is that PHP is stateless and JSP/Servlets is statefull. This leads to the fact that PHP applications (usually) is very easy to scale across multiple servers (i.e. scale very high) whereas JSP/Servlets (usually) is able to scale better when running on a single server - but often have a hard time running on multiple servers without considerable extra engineering.

however bad design/engineering can ruin any chance of an application scaling - both with Java & PHP.

Regards Michael Pedersen PLUSPEOPLE

Nicholas Loki wrote:

...

Hi Skunks, Allow me to disagree with what comrade Saidi mentioned about over-engineering. I think in any enterprise system design a high degree of over-engineering is expected. Personally I would go with start simple but make sure your simple anticipates and expects features that may come up in later releases. About the language of choice, if you want fast turn around times for your development cycles together with ease of use PHP is the way to go. Though I still think it doesn't scale well under increased load. JSPs/Servlets scale very well under load, but are more complex to develop and maintain. Either way you need skills to achieve productivity with both approaches.

Another way to look at it is, you could use a hybrid approach and have PHP for the front end and JSP/Servlets for business logic etc in the back end. You could then use REST APIs or WebServices to pass messages back and forth within the architecture. A bit of an overkill, but might be the way to go with really high volume systems. KR, Loki

Hi Michael/ Skunks, Again allow me to disagree with your statement below:

Said in another way: Java scales best on one server - but once you reach the limit of whatever that application is able to do on that one server, you most likely > have to rebuild large part of your application to make it scale even higher. With Java or should I say a good J2EE app server you can develop you app and deploy it to multiple instances of your app server. These instances are managed by an admin server and you can use a proxy server to route requests with whatever algorithm you prefer. So in essence what we are saying is that to improve perfomance of application X just deploy it on more instance of the app server whether running on the same host or on a different host. That I think is pretty good scaling whether on a single server or on multiple servers. Again its possible we are saying the same thing ;-) KR,Loki "Excellent people exceed expectations". --- On Thu, 9/3/09, Michael Pedersen <sku@kaal.dk> wrote: From: Michael Pedersen <sku@kaal.dk> Subject: Re: [Skunkworks] PHP vs Servlets/JSP To: "Skunkworks forum" <skunkworks@lists.my.co.ke> Date: Thursday, September 3, 2009, 2:24 AM Hi Nicholas & other Skunks, We are saying the same thing ;-) You just explained the difference between the stateless and statefull models. I agree with you that Java on a J2EE server has the potential to scale better than a "normal" PHP application when restricted to one server - however the way you have to code the java app in order to achieve this, is usually the exact techniques that prevent that Java app from using the power of multiple servers. Said in another way: Java scales best on one server - but once you reach the limit of whatever that application is able to do on that one server, you most likely have to rebuild large part of your application to make it scale even higher. (and it is not as if PHP does not scale on one server - it does, just not as good as java) When you then factor in the cost of application development & testing with the ever falling price of hardware, everything is in favor of being able to utilize multiple servers. Prime example is Google - there datacenters are build with the equipment that gives the most processing-power/dollar i.e. many many "normal" servers instead of one "big" one. Finally you _can_ code PHP in a statefull way - if you use e.g. memcache (its just not the default way) - the end result is that the way you structure your application can be exactly the same as when building a J2EE application - and if you really want then you can also code a java application in a stateless way (but there is little point in doing this). All in all - I would say that if you use Java or PHP (or something else) - it does not matter - let personal preference rule depending of the nature of the project naturally. Regards Michael Nicholas Loki wrote:

Hi Michael,   I agree with you on two points. First that PHP can scale well across multiple servers and secondly that bad design/ engineering can ruin any chance of an application scaling whether it be developed in Java or PHP. I think scaling in this case has to be defined and metrics put in place for it to make sense. On a single server with high processing power PHP fails in scaling by virtue of the fact that it runs as an add on module on a Web Servers. JSP/Servlets on the other will run in a Web Container or J2EE server which in turn runs in a JVM. With increased processing power on a single server you can increase the instances of your Web Container/ J2EE server to scale the system. Again scalability has to be defined and metrics put in place for it to make sense. I still think that Java scales better than PHP even on a single server.

KR, Loki   "Excellent people exceed expectations".

------------------------------------------------------------------------ *From:* Michael Pedersen <sku@kaal.dk> *To:* Skunkworks forum <skunkworks@lists.my.co.ke> *Sent:* Wednesday, September 2, 2009 11:22:50 AM *Subject:* Re: [Skunkworks] PHP vs Servlets/JSP

Hi Skunks and Nicholas,

I highly disagree with you that PHP does not scale as well as JSP/Servlets - I will even go as far as to say that it scales better. That PHP does not scale / is enterprise ready is an old myth, one that most likely is a result of the fact that very few PHP applications are engineered with scalability in mind, or is just of poor engineering quality. Prime examples of PHP applications that scale very very well are Wikipedia & Facebook.

The main difference is that PHP is stateless and JSP/Servlets is statefull. This leads to the fact that PHP applications (usually) is very easy to scale across multiple servers (i.e. scale very high) whereas JSP/Servlets (usually) is able to scale better when running on a single server - but often have a hard time running on multiple servers without considerable extra engineering.

however bad design/engineering can ruin any chance of an application scaling - both with Java & PHP.

Regards Michael Pedersen PLUSPEOPLE

Nicholas Loki wrote:

...

Hi Skunks,  Allow me to disagree with what comrade Saidi mentioned about over-engineering. I think in any enterprise system design a high degree of over-engineering is expected. Personally I would go with start simple but make sure your simple anticipates and expects features that may come up in later releases.  About the language of choice, if you want fast turn around times for your development cycles together with ease of use PHP is the way to go. Though I still think it doesn't scale well under increased load. JSPs/Servlets scale very well under load, but are more complex to develop and maintain. Either way you need skills to achieve productivity with both approaches.

Another way to look at it is, you could use a hybrid approach and have PHP for the front end and JSP/Servlets for business logic etc in the back end. You could then use REST APIs or WebServices to pass messages back and forth within the architecture. A bit of an overkill, but might be the way to go with really high volume systems. KR, Loki

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science:  http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi:     http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general

On Tue, Sep 1, 2009 at 3:20 PM, Rad!<conradakunga@gmail.com> wrote:

I don't think the technology is the problem. You will need to answer

Is the team doing the design good? Is the design good (does it cater for concurrency, contention, redundancy, high load etc) Is the team doing the development good, organized and able to work as a team? Is there a project manager and a team lead? In light of the above is the remaining time realistic to do the work?

If the answer to any of these is no then it won't matter what language you use -- you're in trouble either way.

Conrad raises the often forgotten, all-too important "humanware" aspect. Ever insists that software and hardware are not complete solutions by themselves. Think "human."

August 3, 2009 9:14 AM PDT The media sells the Google cloud. The enterprise buys Microsoft on-premises http://news.cnet.com/8301-13505_3-10301766-16.html There's a big disconnect between what the media likes to write about and what the enterprise likes to buy. ... So, the media talks about PHP and other Web-scripting languages, but stodgy chief information officers continue to buy Java and .Net<http://news.cnet.com/8301-13505_3-10296239-16.html> . July 27, 2009 7:49 AM PDT 'Old' tech like Java and .Net is hot in cold economy http://news.cnet.com/8301-13505_3-10296239-16.html If you're part of the "cool kid" developer crowd, you're undoubtedly writing your new application with Ruby on Rails, and spend a lot of time talking about Git, Squeak, or Memcached. But if you want a job, apparently you should get back to ancient technologies like Java and .Net, according to new data from IT employment company Dice.com<http://www.baselinemag.com/c/a/Careers/Nine-Hot-IT-Jobs-in-a-Lukewarm-Market-897905/>, cited in Baseline magazine. In addition to those programming heavyweights, other enterprise bellwethers like Oracle, SharePoint, and SAP also make the cut..... Apparently, new-age Web technologies will get you a date, but old-school technologies are the best bet if you want a job. On Thu, Sep 3, 2009 at 1:08 AM, Joseph Wayodi <jwayodi@gmail.com> wrote:

On Tue, Sep 1, 2009 at 2:47 PM, Ogure Obunga <write2ogush@gmail.com>wrote:

...

...

i'm insisting on the platform because previous attempts on the project using PHP has borne no fruit, though this has more to do with the design on which the system was developed. The initial developer did not put much into consideration when building up the system such that scalability is highly constrained. in which case i prefer starting all over than trying to fix bugs that never end.

To make your life easier, I'd suggest you try a "modern" web application framework such as Grails: <http://grails.org/>. And if you don't mind trying a modern programming language as well, I'd suggest the Python-based Django: <http://www.djangoproject.com/> :)