January 11, 2006
Future is application and coarse components?
The more I think about it, the more I think that software companies need to make off the shelf applications or coarse components that can integrate even with competitors products without a lot of hassle/coding/understanding.
I just spent a few days (spare time) working on a new web site called http://www.trackpedia.com. I made it using open source application components running on a LAMP stack. The cost of hosting that web site is very reasonable and installing those components is an unzip and run a web script affair. I'd say the wiki and bulletin board took 15 minutes each to install and get running on the managed site. If we'd tried to write an Java application to do what we have using the normal stuff like Portals etc, we'd still be talking about it, instead, we're live after a lunch conversation and a few nights effort.
I think Java needs similarly priced hosting solutions to LAMP and equivalent components that are as easy to install or at least Java needs to play in this space as well as the PHP stuff. Things are too complex. Trackpedia was a real eye opener for me as someone who builds middleware for a living. Complex packing schemes like OGSI etc don't help when you compare the ease of use of uploading an unzipped tar file and it's installed. Maybe, we need the WAR to be come the standard software java component. This gives the component an optional web front end if it needs it for running install scripts etc. We need something like OGSI component dependancies but it needs to be real easy. If it's xml based then it's too complex. I think application will use a handful of components, not tens or hundreds of components. It doesn't need to be architected to death.
An issue is how do different components talk with each other easily. OGSI solves this using registries etc but at least in Eclipse is Java centric. I think we need a way to have something similar which isn't Java centric so I can write my web front end in PHP, use a Java cache and a database.
Microsoft COM was cool in that regard. Language neutral. Web services are likely the answer and have some success in this component market. It just needs to be real easy to do and not take tons of memory when its running or lots of tooling. Thats what I don't like about web services, just thinking of installing the tooling discourages me from starting, never mind the runtime.
But, maybe the issue is why do I need stuff like OGSI at all, maybe a script language to just integrate the system is just fine. We didn't do a lot of programming for the site, after all and it's working now including ads etc. It was exactly the lack of the need to write a lot of code that made it so easy and thats what has me thinking about all this. It really was very easy. We could wade in to the source code and it's pretty easy to make it do what you want.
Anyway, food for thought.
January 11, 2006 | Permalink
I've been building LAMP based sites for a while now, and I agree totally about the need for more simplicity in building Java based solutions. It's just too difficult to contemplate for building those get-it-done quick types of applications.
I still have to remind people how easy it is to build working and useful applications on Domino. You can get started very quickly and have a working prototype for users to give you feedback on with relatively little effort.
The one big limitation with a lot of pre-packaged PHP applications is that not many of them support standards. For example: authentication - the ability to utilise a third party LDAP rather than the application's own custom user registry would be a big step forward.
You quite often have to jump through hoops to integrate these pre-built applications into an enterprise environment. But then, that's just a function of how much effort the original application developer went to - it's not as if you can't do these things in PHP, only that not many people go to the effort of doing so.
I recently built a site where I integrated LAMP based components: a wiki, a forum, a "portal", several blogs, a photo gallery, and a document management system. It required me to make modifications to the source code to get a level of authentication integration between them. It's not that this was a massive effort in itself, but by having to modify parts of the source code, I broke the modularity of the applications such that upgrading to the next version of the component requires me to undo and then redo the changes. That's a lot of work required every time a bug fix is issued.
Support for standards is one thing often (but not always) missing from many pre-built LAMP based applications.
But I wouldn't stop using LAMP - the effort is still much, much less than most of the alternatives.
Total cost for building this site ? About $250 worth of software and approaching 100 hours of work. Cost of hosting ? Depends on how much traffic the site generates, but we're talking less than $100 a month. Pretty difficult to beat that.
Posted by: Sim' | Jan 12, 2006 3:39:29 PM
Nice site Billy, are you a track junkie as well?
Posted by: Vincent | Jan 18, 2006 12:16:37 AM
Fraid so. Check out my porsche blog or trackpedia, got it bad man.
Posted by: Billy | Jan 18, 2006 12:31:56 AM
Eclipse is delivered in a zip file and is up and running in 3 minutes. I do not think that is the interesting problem. The interesting problem is when 2, 3, 5, 10, 50, 100 different applications must work together.
I agree with your complaint that Java and XML files are often too hard. Script files are often more than sufficient for many web like apps and are much quicker to debug. However, you can use script files with an OSGi component approach as well.
I am sorry to hear that you think making bundles is hard. Can you elaborate? I often see people making designs that are overly complex and coupled, causing highly complex manifests. Cohesive components usually share and require very little.
I think the current problem is that we do not have a streamlined bundle repository where it is easy to find components that you can use to build your applications. As far as I can see, OSGi is the only real player in the field of building applications form high level components. However, I fully realize we have lots of work left, especially in the web application market.
Posted by: Peter Kriens | Jan 20, 2006 2:42:26 PM
I really understand your delimma with the LAMP vs. Java question. I've been doing .NET for a few years, and there's no comparison between C#/ASP.NET and LAMP. It's faster, cheaper for 90% of the web apps I see.
The one thing however is that people in the corporate world are still somwhat reluctant to use LAMP, even on Intranets because they fear the support issue.
All in all I love PHP/MySQL and it's a heck of a lot faster.
Posted by: John Swaringen | Jan 24, 2006 4:52:21 PM