What is SOA?
Big news. Gartner predicts the Service Oriented Architecture (SOA) market to explode.
I'd provide a link to the article, but really... Is anyone surprised that Gartner is predicting the explosive growth of anything?
Okay, let's be fair here. The problem isn't whether Gartner is right, although in this case I happen to agree with their assessment. The problem is the definition of SOA. If you poke at it enough, you'll quickly find that SOA as a technology expands far and wide. Anything with an XML interface is going to fall under the definition of being SOA enabled as far as the vendor is concerned. This little detail makes the market definition tricky.
Taking the market analysis hat off for a minute, the bottom line is that an enterprise looking to break their application architecture up into bite sized modules that communicate via web services, SOA is the hot tip. You want to know why? Dust off the history book, it's time for a quick read...
When application development software started back in the 1960s, there was really no significant network to communicate on. Application software was written as monolithic blobs of code and modularity was enforced at an architectural level. As applications became increasingly unwieldy and the size of servers grew, the justification for object oriented programming came with it. Modularity beyond objects took form as intra-process communication on large SMP servers. Networks being relatively slow weren't the ideal choice for using as a intra-process communications. Unless you could afford an extremely low latency specialty network, it just wasn't a practical solution.
Now come around to the mid-90s. The 100Mbps Ethernet standard had taken shape and the cost of network infrastructure for it was relatively affordable. The Parallel Virtual Machine (PVM) libraries and the Message Passing Interface (MPI) standard emerged in 1989 and 1994 respectively, which made software development for distributed software much easier. The result was that cluster computing had a genuine shot at taking down the requirement of large and expensive SMP machines for the first time. It also meant that intra-process communication had really standardized in a cross-platform way.
The problem with MPI and PVM, however, is that they stayed largely aimed at the High Performance Computing (HPC) space. Furthermore, while it is possible to use them in an object oriented context, they don't easily lend itself to that model. Now pause this development for just a second and hop over the XML crowd.
Mid to late 90s saw the resurrection of SGML in the simpler form of XML after HTML had become the black sheep of the SGML children. In 1998 saw the first development of SOAP as an XML based intra-process communication mechanism. SOAP really started seeing the light of day when Microsoft made a big push for their .Net architecture around 2002/2003.
So here you have it... Applications are getting big. Networks are fast and relatively cheap. Big iron SMP machines are getting more expensive while clusters of cheap PCs running server class operating systems are readily available. The web movement showed that breaking up applications into horizontally scalable solutions is not only doable, it is preferable. But enterprise applications are still missing their version of MPI. Their version to make machine to machine communication really click.
Microsoft may have dropped the ball with the .Net marketing campaign, but it did get enough developers on the .Net bandwagon that critical mass was reached. Finding a .Net capable programmer that understands how to leverage web services for intra-process communication means visiting your local HR department, not hunting down some obscure HPC deployment doing atomic bomb simulations. Lucky for for us marketing-types, IBM picked up the ball and did a stellar job of coining SOA and making it fully buzzword compliant with CIO visibility.
So going back to the original question... What exactly does and should the "SOA market" constitute? Really, I don't think it matters. What matters is that SOA, or more accurately, SOAP, is the key enabler to make big applications easier to modularize across clusters of small (virtual?) machines in a datacenter. Over the next 10 years, I believe that this has the potential to put some serious hurt on the SMP market (10% of server units, 50% of server revenue). SOA may be fully buzzword compliant, but I genuinely think it's going to change the way applications are written.
Of course, if you really need a market number... Cite me. Rising Edge Consulting puts the SOA CAGR at 134%. I'll be happy to discuss my findings. Did I mention I was a consultant for hire? Contact me, and we'll discuss your needs.
Oh, and tube socks... Even bigger. I have a whole team of researchers working on that.
I'd provide a link to the article, but really... Is anyone surprised that Gartner is predicting the explosive growth of anything?
Okay, let's be fair here. The problem isn't whether Gartner is right, although in this case I happen to agree with their assessment. The problem is the definition of SOA. If you poke at it enough, you'll quickly find that SOA as a technology expands far and wide. Anything with an XML interface is going to fall under the definition of being SOA enabled as far as the vendor is concerned. This little detail makes the market definition tricky.
Taking the market analysis hat off for a minute, the bottom line is that an enterprise looking to break their application architecture up into bite sized modules that communicate via web services, SOA is the hot tip. You want to know why? Dust off the history book, it's time for a quick read...
When application development software started back in the 1960s, there was really no significant network to communicate on. Application software was written as monolithic blobs of code and modularity was enforced at an architectural level. As applications became increasingly unwieldy and the size of servers grew, the justification for object oriented programming came with it. Modularity beyond objects took form as intra-process communication on large SMP servers. Networks being relatively slow weren't the ideal choice for using as a intra-process communications. Unless you could afford an extremely low latency specialty network, it just wasn't a practical solution.
Now come around to the mid-90s. The 100Mbps Ethernet standard had taken shape and the cost of network infrastructure for it was relatively affordable. The Parallel Virtual Machine (PVM) libraries and the Message Passing Interface (MPI) standard emerged in 1989 and 1994 respectively, which made software development for distributed software much easier. The result was that cluster computing had a genuine shot at taking down the requirement of large and expensive SMP machines for the first time. It also meant that intra-process communication had really standardized in a cross-platform way.
The problem with MPI and PVM, however, is that they stayed largely aimed at the High Performance Computing (HPC) space. Furthermore, while it is possible to use them in an object oriented context, they don't easily lend itself to that model. Now pause this development for just a second and hop over the XML crowd.
Mid to late 90s saw the resurrection of SGML in the simpler form of XML after HTML had become the black sheep of the SGML children. In 1998 saw the first development of SOAP as an XML based intra-process communication mechanism. SOAP really started seeing the light of day when Microsoft made a big push for their .Net architecture around 2002/2003.
So here you have it... Applications are getting big. Networks are fast and relatively cheap. Big iron SMP machines are getting more expensive while clusters of cheap PCs running server class operating systems are readily available. The web movement showed that breaking up applications into horizontally scalable solutions is not only doable, it is preferable. But enterprise applications are still missing their version of MPI. Their version to make machine to machine communication really click.
Microsoft may have dropped the ball with the .Net marketing campaign, but it did get enough developers on the .Net bandwagon that critical mass was reached. Finding a .Net capable programmer that understands how to leverage web services for intra-process communication means visiting your local HR department, not hunting down some obscure HPC deployment doing atomic bomb simulations. Lucky for for us marketing-types, IBM picked up the ball and did a stellar job of coining SOA and making it fully buzzword compliant with CIO visibility.
So going back to the original question... What exactly does and should the "SOA market" constitute? Really, I don't think it matters. What matters is that SOA, or more accurately, SOAP, is the key enabler to make big applications easier to modularize across clusters of small (virtual?) machines in a datacenter. Over the next 10 years, I believe that this has the potential to put some serious hurt on the SMP market (10% of server units, 50% of server revenue). SOA may be fully buzzword compliant, but I genuinely think it's going to change the way applications are written.
Of course, if you really need a market number... Cite me. Rising Edge Consulting puts the SOA CAGR at 134%. I'll be happy to discuss my findings. Did I mention I was a consultant for hire? Contact me, and we'll discuss your needs.
Oh, and tube socks... Even bigger. I have a whole team of researchers working on that.
posted by Steve Shah at 1:45 PM
1 Comments:
SOAP is the key enabler? I'm skeptical. SOA a lot easier to debug and deploy when using simpler, more RESTful protocols. Remember, the S stands for Simple.
Post a Comment
<< Home