Posts

An open letter to Jonathan Schwartz

Image
This post was also published in InfoWorld. Dear Jonathan, Long time no see! The same way you enjoy writing open letters to IBM and others in your blog -- I wanted to write an open letter to you and Sun, and see if I can get a little clarity about your open source software strategy. As I am sure you have noticed, there has been quite a bit of momentum around LAMP in the industry, ranging from innovators like Google, Yahoo!, and Amazon, to the "Web 2.0" crowd like Friendster, MySpace, and Flickr. In addition, LAMP has increasing usage in the enterprise. The "P" languages in LAMP -- PHP, Python, and Perl -- are all open source, and each provide their own virtual machine. It would be ideal if the Java JVM was open source so that open source projects like PHP could join up with the Java Virtual Machine. In turn, Java would be much more competitive with .Net, which supports numerous languages out of the box. Initiatives like adding dynamic language support in the JV...

Confounding: Sun vs. scripting languages

Image
This post was also published in InfoWorld. During my five year tenure at Sun, Graham Hamilton, the Java CTO, killed every initiative to run scripting languages on the Java Virtual Machine. These include 1999's "javab", which would have run Visual BASIC syntax on the JVM, and 2003's "Java 3", which would have supported optional typelessness for Java objects. Clearly, the industry trend towards scripting languages like PHP and Ruby has finally had an effect, since Graham has recently sponsored JSR 292: Supporting Dynamically Typed Languages on the JavaTM Platform . The time lag here is similar to the time lag it took Graham to support SOAP in favor of RMI after a ton of resistance, which Sun paid for dearly when they had minimal impact in the development of the web service standards we use today. It's great that Sun has finally decided to support scripting languages in some way in the next couple of years. However it is clear that this change was...

Integrate on the Front End with Lightweight Architecture

Image
This post was also published in InfoWorld. "Integration" is the third rail of enterprise IT. The mere mention of the word raises terrifying thoughts of huge budgets, endless meetings, and extremely complicated software. But the days where each enterprise application is an island are coming to an end--even things as simple as an employee directory now need to integrate the HR systems of multiple divisions, accommodate cross-reporting and virtual teams, and integrate outsourced third parties. Like it or not, essentially every enterprise application today requires integration. Naturally, enterprises have taken notice of the rise of "mash-up" applications on the Internet that integrate data from a variety of sources in new and useful ways. The trend was kicked off with sites like Housingmaps.com , which displays Craigslist housing listings on Google Maps, and has now reached quite a pinnacle with a conference called Mashup Camp where numerous people demonstrated ...

Enterprise SOA apps take off on lightweight architecture

Image
This post was also published in InfoWorld. At the last InfoWorld SOA Executive Forum , I asked the audience for a show of hands on the following question: "Who thinks it's easier to build an app that communicates to a web service than it is to write an app that communicates to a database?" Of this very sophisticated audience of senior IT architects and managers only two people raised their hands. After having spent countless amounts of time and money implementing service-oriented architectures, enterprises are finding that it's still incredibly difficult to build new user-facing applications that tie services together. Why? Because enterprises are trying to build composite apps with traditional technologies such as J2EE. It's hard enough using this approach to build a basic HTML application that talks to a single database. It is nearly impossible when you're using the same tools to create applications with rich interfaces that integrate with multiple service...

Doing big things with lightweight architecture

Image
This post was also published in InfoWorld. Quite a few folks are beginnning to realize that most big websites, including Yahoo!, Google and Amazon.com, run on lightweight architecture. To define lightweight architecture, it is helpful to define its opposite: Heavyweight architecture means you are running complicated infrastructure software like J2EE with complicated API's on a small cluster of expensive SMP machines. Lightweight architecture means you are running straightforward, open source software stacks with service oriented API's on large clusters of commodity machines. There are four common ways of achieving a lightweight architecture. Three of them are open source solutions, and the fourth is Microsoft's attempt: LAMP - As many of you know LAMP is my favorite lightweight stack. LAMP runs a vast majority of the massively scalable websites out there, and is also the favorite deployment stack for most of the "Web 2.0" crowd, including Friendster, Facebook, M...

BusinessWeek article about LAMP stack, Slashdotted again

There was a great article about LAMP and ActiveGrid by Steve Hamm in BusinessWeek today that was Slashdotted and started YAFF (yet another flame war) very reminiscent of when we were Slashdotted last year. To sum up the article, it lists a few indisputable facts: Google, Yahoo, and a lot of Web 2.0 companies such as Friendster, Flickr, and Facebook are using open source stacks like LAMP instead of Java. There are more and more developers and websites using PHP, as evidenced by booksales and Netcraft stats. Companies like Merrill Lynch write processor intensive code in C/C++ directly on Linux and script it rather than use Java API's, presumably because they want more perfromance and do not care about platform portability out of Linux. .Net is getting used a lot more in enterprises (something I have seen in quite a few large accounts and which Sun even acknowledges in the article). "Earlier this year, [IBM] threw its weight behind PHP as a Web programming language....

The end of desktop software

Our engineering team has grown quite a bit, and I needed to better track our 1.0 release process. It has been a while since I have directly managed an engineering project, but I have done it before with Microsoft Project. So I order it and it arrives a couple of days later. I then had a very bizarre experience, almost like an archaelogical dig. It was a shrink wrapped box entitled "Microsoft Project 2003". 2003??? This code hadn't been touched in three years! I opened the box (yes, it is still a pain) and took out the CD and installed the software. I haven't installed software like this in years. I then entered everybody's tasks, task hierarchies, and such. Project was incredibly difficult to use, stuff that should have been obvious was very obtuse. Then I wanted to publish the Gantt chart in HTML for our intranet. Tried for hours. Couldn't do it. Finally I printed out the chart, taped six sheets of paper together, and posted it on the wall in our ...

Web 2.0: Don't try this at work

One of the big drivers of Internet applications in the corporate world was the stark contrast of what people could do at home and at work: At Home: Buy books, buy movie tickets, look up the weather, etc. At Work: Call HR to change health plan, call factory floor to find out what happened to customer's order, call invoicing to find out what happened to a bill, etc. Well clearly something at work was wrong, and soon enough everything was online. :) Now look at the difference between home and work today: At Home: Web applications are using JavaScript and DHTML to enhance the user experience and decrease server interactions. Some random guy can combine Google Maps and Craigslist apartment listings in a useful way without talking to either Google or Craigslist ( http://www.paulrademacher.com/housing/ ). At Work: Everything has a Netscape 3 level of UI interactivity and nothing works with anything else. This difference in functionality and the increasing expectations of users will lea...

WS-Nothing

A couple of weeks ago I participated on an application server panel at Web Services Edge hosted by Anne Thomas Manes. There was quite a bit of discussion about WS-This and WS-That and WS-Foo and WS-Bar. Essentially, this Web Services thing has devolved into a huge unintelligible morass. The panel was covered today in LinuxWorld , which liked an ad-hoc term I used: WS-Nothing . Vendors Have Been Arguing for So Long That You Have to Send Text Files Around On the panel, I said that we vendors have lost sight of the fact that we have been bickering so long that the only way our products can talk to each other is to send text files around. We are now in the process of screwing even that up with all of these competing specifications about how to mark up self-describing text files. It is of no supprise that Web Services have not had a big uptake with customers; they don't even know where to start. The point of web services is interoperability, and if the Web Service produced by a particul...

"Local" Web Services

In a world where applications are increasingly being defined by declarative XML like BPEL, XForms, XPath, it is becoming cumbersome and complicated to incorporate all of those definitions into procedural applications. But perhaps the tail has been wagging the dog. If the flow of an application, the interface points to external entities, its user interface, and its queries are all defined in XML, perhaps it is time to simply admit that the application is written primarily in XML and that logic must be integrated with the XML defined application, not the other way around! Of course the obvious integration point for such an architecture is web services, which clearly is not ideally suited for adding snippets of code or for having a bunch of internal methods that call each other and share the same dataset. What is needed is a method to have a web service that is treated like a local method call, much like in the CORBA days there was a way to do a local IIOP call. The concept of Local...