In recent years there has been a discernible shift in the paradigms that dictate standards and protocols in the world of software development and dissemination. In the late nineties, developers and users alike had come to see the old paradigms of ‘closed source’ development of proprietary software as a fusty anachronism that was no longer applicable to a world in which technological advance dictates ever more rapid change and solicits technological solutions that are uncongenial with the previous ‘closed’ conditions of software development that had obtained previously.
In his1997 essay The Cathedral and the Bazaar, Eric S. Raymond proposed – using the architectural analogy of Cathedral and Bazaar – that the vast monoliths of ‘Cathedral’ style software development should and will be displaced by a paradigm that is more promiscuous and inclusive in its in its ethos and applications. If previous decades have known software modules as proprietary monads that cannot countenance end-user tweaking subsequent to their commercial official release, the contemporary software development creed of ‘open source’ code has embraced a more pluralistic and communal sense of software design. Code – not bug fixes – is disseminated among users and they are free to tailor it to their needs.
This Cathedral style development is, as Raymond indicates, necessarily cabalistic, and disbars the average user from manipulating to his advantage a piece of software that is tailored to no individual but rather to a generic, universal user. Under such condition the end product becomes ‘fully crafted by individual wizards or small bands of mages working in splendid isolation.’ This ivory tower ethos necessarily promulgates software that is recalictrant to change and unheeding to end-user requirements.
What Raymond calls for and indeed what has seen rapid proliferation over recent years is the notion of the Bazaar; this ‘great babbling bazaar of differing agendas and approaches’ suttures the previous split between developer and user. The code remains open to the public domain and rather than remain statically within the hermetic realm of corporate code, it is amenable to the various needs of its innumberable users. This ethos compromises the ‘architecural’ integrity of the code, but what it loses in the undermining of its foundations; it gains in the number of potential architects who are able to butress any subsidence and tweak its code. As Raymond says, that software is ‘open source’ doesn’t preclude its entry to the world of properly commerical software solutions; rather, the fact that the code is openly corrigable means that any latent security and operational bugs will be ironed out far more quickly than with a properitary piece whose code remains invioably with the manadarins of Catherdral design. “Linus’ Law”, as Raymond terms it, means that the vast array of users with a vested interest in the success of the sofware means that bug fixes cannot but be expidited:
“given enough eyeballs, all bugs are shallow” (which he terms Linus’ law): the more widely available the source code is for public testing, scrutiny, and experimentation, the more rapidly all forms of bugs will be discovered. In contrast, Raymond claims that an inordinate amount of time and energy must be spent hunting for bugs in the Cathedral model, since the working version of the code is available only to a few developers.
PHP is one such Bazaar style open source languages that were originally designed for producing dynamic web pages. One of many such languages, PHP has as its main rivals ASP, Pearl and JavaServer pages to name but a few. There are numerous pros and cons pertaining to each of the languages, but PHP’s main advantage lies with its ability to cross various OS platforms and operate under various application and server conditions:
Originally designed to create dynamic web pages, PHP’s principal focus is server-side scripting. While running the PHP parser with a web server and web browser, the PHP model can be compared to other server-side scripting languages such as Microsoft‘s ASP.NET system, Sun Microsystems’ JavaServer Pages, mod_perl and the Ruby on Rails framework, as they all provide dynamic content to the client from a web server.
Its adapatability and its amenability to most web servers and nearly every operating system has propelled it to Internet success, success evidenced by the ninteen million Internet domains hosted on PHP servers. PHP clearly has this advantage over Microsoft’s ASP system; for ASP is a ‘natively used only on Microsoft Internet Information Server (IIS). This limits it’s availability to Win32 based servers.’ ASP can be converted to other systems, but the fact that it remains a Microsoft proprietary system limits its applicability somewhat.
Perhaps PHP’s main rival, Perl has been around – in technology terms – since time immemorial. It is well established and has become a sophistcated, multilayered langauge that in terms of scope outdoes PHP. Yet Perl’s sopshistication can be a hindrance, especially when compared with PHP’s pared-down, concise and flexible nature. It’s flexibility is partcualarly evident in its ability to cooperate with other established Internet languages and protocols, especially that Internet commonplace HTML:
PHP is easier to integrate into existing HTML than Perl. PHP has pretty much all the ‘good’ functionality of Perl: constructs, syntax and so on, without making it as complicated as Perl can be. Perl is a very tried and true language, it’s been around since the late eighties, but PHP is maturing very quickly.
Although PHP comes out on top in many of these comparisons, developers realise that the more comprehensive suite or framework of tools is a necessity if it is to be considered on a par with proprietary big boys such as Microsoft. At the forefront of this development is the Zend framework that hopes to afford PHP a greater sense of rigour and formality:
To more directly compete with the “framework” approach taken by these systems, Zend is working on the Zend Framework – an emerging (as of June 2006) set of PHP building blocks and best practices; other PHP frameworks along the same lines include CakePHP, PRADO and Symfony.
As with open source languages, the advantages of a distributed, flexible framework of Web Services also contain a necessary downside. Their modularity means that they can be expanded efficiently and without overhauling of previous paradigms, yet this modularity means that apart from their core specifications (SOAP, WSDL, UDDI etc), other specifications are ad-hoc and contigent on the vagaries of circumstance:
The specifications that define Web Services are intentionally modular, and as a result there is no one document that contains them all. There is also no single, stable set of specifications. There are a few “core” specifications that are supplemented by others as the circumstances and choice of technology dictate
For business these Web Services have many advantages, but critics point to the inefficiceny of XML message format and the SOAP and HTTP enveloping it:
There are also concerns about performance, because of Web services’ use of XML as a message format and SOAP and HTTP in enveloping and transport.
There is criticism, too, of the vagaries of unstandarised services and the confusion and ambiguity arising from a system where there is little consensus with many services produced on a ad hoc basis:
Critics of non-RESTful Web services often complain that they are too complex and biased towards large software vendors or integrators, rather than open source implementations.