I believe it was this article which prematurely blew the lid on a new protocol called AMQ.
Even the SOA Group is speculating....
The answer is... wait and see. I've been told by the best of sources that this project will be unveiled shortly...
Sunday, February 27, 2005
N-Service Computing
Explaining Web Services, SOA and related concepts isn't always so easy. In my attempts to make these concepts easy to understand by the masses, I've landed on the term "N-Service Computing". And I'm using the following diagram to explain what I mean:
I've found that by showing this simple diagram people usually understand a few key points:
1. Service computing is an evolution of prior efforts
2. Services are the new unit of work
3. Services are part of a network
Obviously, this single slide doesn't explain everything, but I've found it to be a good introduction.
I've found that by showing this simple diagram people usually understand a few key points:
1. Service computing is an evolution of prior efforts
2. Services are the new unit of work
3. Services are part of a network
Obviously, this single slide doesn't explain everything, but I've found it to be a good introduction.
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.
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.
Tuesday, February 22, 2005
SOA, Just an Application Server?
BEA's Alfred Chuang was recently quoted:
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.
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.
Thursday, February 10, 2005
Semantic Web Services
I've had several inquiries about semantic web services; I believe related to the recent predictions made by Graham Glass.
Personally, I'm a big fan. However, I'm thinking that the adoption curve of RDF, OWL and semantic ontologies is pretty far out. The use of first order predicate calculus applied against a structured knowledge base is an excellent idea (in peer to peer mode, when based on 'web of trust'), but again - this is quite a ways out as well. However, with Microsoft moving aggressively with XML in their products and now offering their "Information Bridge Framework", we will begin to see more emphasis on structured information being related by "exact match". By this I mean that the XML schema becomes a 'pivot point'. So, an XML schema that talks about "company X" may have several 'pivots': Company X's Partners, Products, Employees, etc. Thus the user will have the ability to 'navigate structured information'. With the inclusion of semantic ontologies, there will be less emphasis on having the pivot points being exact matches only. Eventually, the pivots will be navigable by synonym, hyponym or hypernym. This is extremely exciting capability, taking office productivity to a new level.
Most organizations tend to think of their web services and SOA efforts as "back office" functionality - a way to connect legacy systems. I am a firm believer that we will see a huge upside when we connect smart services to end user productivity tools. Like most people, I spend most of my day in a handful of tools: e-mail, word processing, spreadsheet, etc. Empowering users through better information is good business.
For those of you who've never queried a semantic ontology, give this a try:
http://www.cogsci.princeton.edu/cgi-bin/webwn
Make sure you look at hypernyms and hyponyms. If you're real interested check out the book "WordNet". I also recommend looking at the Cyc effort.
Personally, I'm a big fan. However, I'm thinking that the adoption curve of RDF, OWL and semantic ontologies is pretty far out. The use of first order predicate calculus applied against a structured knowledge base is an excellent idea (in peer to peer mode, when based on 'web of trust'), but again - this is quite a ways out as well. However, with Microsoft moving aggressively with XML in their products and now offering their "Information Bridge Framework", we will begin to see more emphasis on structured information being related by "exact match". By this I mean that the XML schema becomes a 'pivot point'. So, an XML schema that talks about "company X" may have several 'pivots': Company X's Partners, Products, Employees, etc. Thus the user will have the ability to 'navigate structured information'. With the inclusion of semantic ontologies, there will be less emphasis on having the pivot points being exact matches only. Eventually, the pivots will be navigable by synonym, hyponym or hypernym. This is extremely exciting capability, taking office productivity to a new level.
Most organizations tend to think of their web services and SOA efforts as "back office" functionality - a way to connect legacy systems. I am a firm believer that we will see a huge upside when we connect smart services to end user productivity tools. Like most people, I spend most of my day in a handful of tools: e-mail, word processing, spreadsheet, etc. Empowering users through better information is good business.
For those of you who've never queried a semantic ontology, give this a try:
http://www.cogsci.princeton.edu/cgi-bin/webwn
Make sure you look at hypernyms and hyponyms. If you're real interested check out the book "WordNet". I also recommend looking at the Cyc effort.
Subscribe to:
Posts (Atom)