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 services including RSS, SOAP, REST and database stored procedures. Java is great for doing certain kinds of applications, including things like ERP systems and transaction orchestration. It is not ideally suited to line-of-business IT types of developers trying to rapidly develop rich new applications that integrate services from an SOA infrastructure.
On the Internet, composite applications are commonly called "Web 2.0" or "mashup" applications, and feature rich AJAX user interfaces that integrate data from multiple data sources. If you look at Web 2.0 companies that are having success, such as Facebook, flickr, Friendster, and MySpace, they're all running a lightweight architecture, the open source LAMP (Linux, Apache, MySQL, PHP/Python/Perl) stack on large clusters of commodity machines.
When "Web 1.0" happened, consumers could use their computers to buy plane tickets, check the weather, and buy books. But when they went to work, if they wanted to change their health plan, they had to call HR. If they wanted to find the latest price of a part, they had to call their supplier and have a price sheet faxed to them. This disconnect between home and work life very quickly evaporated, and now virtually all information that people need at work is available online.
Large organizations need to quickly deliver composite apps, like CRM applications that integrate services. That way they can show, for example, that a customer's last five orders have been delayed before they make a sales call and get ambushed by an irate person on the other line. Before the web, the user facing applications within an enterprise were usually written with scripting languages like Visual Basic and Powersoft's PowerScript. By using the next generation of scripting languages PHP, Python, and Perl -- instead of Java, line of business IT can create applications much more rapidly that integrate diverse services, bringing Web 2.0 style applications to the enterprise.
2 comments:
Thats a confusing picture. What on earth does this have to do with java?
And google use java as their number 2 language, and still have the "light" architecture.
I think you're reasoning is faulted.
You go from stating that a framework (J2EE) isn't suitable for implementing new age web apps to the conclusion that Java is therefore not appropriate in these situations either.
Java is more than capable of being used for this kind of work. The real problem is that everyone immediately jumps on J2EE as the solution before they've even thought about the problem.
Dan Creswell
http://www.dancres.org/
Post a Comment