Service Oriented Enterprise


Friday, February 25, 2005

WS-LAMP  

Dozens of bloggers have discussed the use of the LAMP stack as a foundation for SOA and service oriented construction. However, the "P" in LAMP traditionally meant using one of several dynamic languages like Perl, Python or PHP. Today, IBM announced their blessing of PHP and is announcing that it will become more Web service friendly. This may be the first of several steps to redefine their core programming strategy, see:

http://news.com.com/Big+Blue+backs+PHP+for+Web+development/2100-7344_3-5589559.html?tag=nefd.top

Clearly, IBM has to be very careful about what they are doing here. The last thing they want is to introduce confusion around their core Java based WebSphere products. However, IBM has excellent disciplines around milking mature products and introducing stars without prematurely killing their cash cow. It will be interesting to watch them slowly commercialize this area. They'll want to be perceived as a leader in the space (by geeks) while simultaneously disavowing the concept to CIO's until the calculus tells them that there is more profit in slaughtering the cow and having the feast - - but this is clearly no time soon.

That said we have a conundrum. Generally speaking, the "open source types" prefer simple mechanisms over complex ones. In the Web services world this means that they like "REST" not "WS-*". Now, IBM has a different view - - they fundamentally understand the value proposition of decoupling functions from their non-functional concerns. IBM realizes that mission critical systems require policy based agreement to the ilities. More importantly, they understand that the compose-ability of services increases with the ubiquitous commoditization of the non-functional concerns... and you're average open-sourcer, well, doesn't even know what that means.

IMHO, we can expect to see IBM fund the research, technology, engineering and marketing around the WS-LAMP space. This might be look like an open source play, but long term, this is an enterprise move.

posted by jeff | 3:02 PM


Tuesday, February 22, 2005

SOA, Just an Application Server?  

BEA's Alfred Chuang was recently quoted:

Are your new products, like Quicksilver (messaging integration software) a way to diversify your products?
It's not to diversify. It's filling the parts. At our size, we can't just sell products anymore. We have to sell both products and vision. We don't have a choice. We can't just keep selling the application server, saying, "But this is SOA. SOA is just an application server." We've got to tool it enough so that people say, "Ah, I understand."


It is good to see that BEA sees SOA as more than just an application server. What is less clear is if they intend to leverage their application server assets as the core to their SOA strategy.

I understand why BEA may decide to position the SOA battle on AppServer-Hill. They own that hill (or at least they used to). Is it possible that the BEA army will be waiting on the wrong hill for a battle that will never occur? Perhaps - or perhaps IBM will bring the battle to that hill knowing that 1. They can 2. They'll easily beat BEA. And of course, Microsoft will state that AppServer-Hill doesn't even exist.

Competitors will take the battle to a new hill, ServiceNetwork-Hill. They'll argue that clumping a bunch of tightly coupled Java API's together under session-clustered JVM's is silly. They will also be quick to note the 'coupling levels' within the J2EE platform and the fact that it was hard coded to support three configurations: one-tier, two-tier and three-tier (not N-Service). The competitors will tell you to read the J2EE blueprints and best practice guides to reinforce their point. The J2EE stack fundamentally wasn't designed to support a distributed service network. It's very name "application server" seems to reinforce it's goal. The complete lack of progress in the JSR arena on creating 'service networking' concepts indicates the strategy, resource allocation and potential adoption timelines.

It is extremely hard to make the transition from one paradigm to the next. When I was employed by a mainframe software company, it was clear to me that the client-server guys were going to kick our butts. It was equally clear that the application service guys were going to win over the PowerBuilder types. And yes, to me, it is once again clear that the service network guys will win over the application server companies.

The door has been left wide open to the startups to create the next big thing in enterprise computing. I wish you the best of luck.

posted by jeff | 4:56 AM

archives