We've had lots of debates about what SOA means to different people (thank goodness SOA 2.0 seems to be dying!), what is the exact definition of ESB and how it relates to SOA, SOA versus REST etc, so it's fair to say that SOA is here to stay, at least until the next TLA comes along.
I think we can all pretty much agree that SOA is not purely something that comes in a shrink-wrapped box. However, the central principles behind SOA (services, messages and the triad of producer/consumer/registry) are implementation agnostic (I could use CORBA just as much as SOAP/HTTP). Everything else is almost entirely left to implementation approaches. So UDDI for registry; SOAP/HTTP for interactions; WSDL and WS-Policy for contract definitions. Unfortunately this is only good up to a point: if you are happy living in a Web Services world then you are (almost) covered completely (or will be if you let OASIS and W3C do their jobs over the next few years or so).
However, as I said before, SOA is implementation agnostic and many people want to embrace SOA principles but not Web Services. There are a number of reasons for this, but often the common ones include performance, existing investments and stability of Web Services implementations. There is a lot of effort being expended in the WS-* (r)evolution. Many ESBs now offer Web Services support and use this to justify their SOA credentials (conveniently ignoring the fact that it is just as easy to build non-SOA applications in Web Services as elsewhere).
There has been some good work in OASIS on defining a SOA Reference Model and SOA Blueprints (patterns of use), but so far this has not been taken up by the majority players in either SOA or ESB. Are the big vendors such as IBM and Microsoft really only interested in Web Services as far as SOA is concerned? Are we at risk of losing the bigger SOA picture in favour of Web Services? Is that such a bad thing anyway?
Maybe the majority of users and developers looking to embrace SOA really only want Web Services and it's a vocal minority who complain at the lack of support elsewhere? I believe it would be bad for our industry if we lose sight of SOA and concentrate solely on Web Services. I'm not saying that Web Services are bad (for better or for worse I've been involved in helping their evolution since 1999/2000), only that this is definitely a case of using the right tool for the right job. If we can continue to separate SOA from Web Services, then maybe we don't have to worry about legacy Web Services applications in a few years time.
Editors Note: Mark Little is a new regular news editor for the SOA community on InfoQ.
I think we can all pretty much agree that SOA is not purely something that comes in a shrink-wrapped box. However, the central principles behind SOA (services, messages and the triad of producer/consumer/registry) are implementation agnostic (I could use CORBA just as much as SOAP/HTTP). Everything else is almost entirely left to implementation approaches. So UDDI for registry; SOAP/HTTP for interactions; WSDL and WS-Policy for contract definitions. Unfortunately this is only good up to a point: if you are happy living in a Web Services world then you are (almost) covered completely (or will be if you let OASIS and W3C do their jobs over the next few years or so).
However, as I said before, SOA is implementation agnostic and many people want to embrace SOA principles but not Web Services. There are a number of reasons for this, but often the common ones include performance, existing investments and stability of Web Services implementations. There is a lot of effort being expended in the WS-* (r)evolution. Many ESBs now offer Web Services support and use this to justify their SOA credentials (conveniently ignoring the fact that it is just as easy to build non-SOA applications in Web Services as elsewhere).
There has been some good work in OASIS on defining a SOA Reference Model and SOA Blueprints (patterns of use), but so far this has not been taken up by the majority players in either SOA or ESB. Are the big vendors such as IBM and Microsoft really only interested in Web Services as far as SOA is concerned? Are we at risk of losing the bigger SOA picture in favour of Web Services? Is that such a bad thing anyway?
Maybe the majority of users and developers looking to embrace SOA really only want Web Services and it's a vocal minority who complain at the lack of support elsewhere? I believe it would be bad for our industry if we lose sight of SOA and concentrate solely on Web Services. I'm not saying that Web Services are bad (for better or for worse I've been involved in helping their evolution since 1999/2000), only that this is definitely a case of using the right tool for the right job. If we can continue to separate SOA from Web Services, then maybe we don't have to worry about legacy Web Services applications in a few years time.
Editors Note: Mark Little is a new regular news editor for the SOA community on InfoQ.