Perhaps the semantics problem results from the fact most people still mistakenly think SOA is all about integration. It is not. It is about Architecture, hence the "A" in the acronym. Architecture is not integration, although you can use an architectural description language such as UML to capture the architecture of your integration project. Do you see where I am going with this?
InfoWorld's Paul Krill starts his article with a strange notion:
"SOA is dead but services remain alive, according to a prominent analyst who published an obituary for SOA in a blog post on Monday."
Now correct me if I am wrong, but SOA is "Service Oriented Architecture". Is Paul implying that architecture that is oriented around services is itself dead, yet the services will exist? This makes no sense as everything has an architecture, whether explicit or not. I also have a lot of respect for Paul Krill and his article was very balanced, exploring some of this.
Services are certainly the mainstay of the new web revolution. Things like SaaS, Mashups and most RIAs depend upon services. I am going to disagree and state that architectures will continue to focus around services as the abstract boundary between needs and capabilities for a long time. In fact, the OASIS SOA Reference Model describes the pattern extremely well and it is durable in that it is not coupled to current technology families like Web Services. SOA is here to last and will last!
Where I can see that there are some aspects dying is the families of technologies that are used to implement SOA have become somewhat passe or too complex. From this standpoint, implementing SOA using the current WS-* stack is a daunting task. This is summed up well in Mark Hansen's "SOA Using Java Web Services". In this book he writes on page 2:
"Am I stupid or are Java Web Services really hard?"
The summary is that, in fact, the WS implementation of SOA fact becoming increasingly complex. Having worked on many of the current standards or just observed their work, things like WS-TX, profiles for Kerberos for WS-Security and the JAXB serialization/deserialization are in fact very advanced technologies and take a lot of forethought. This in turn, will drive many developers to use a REST style SOA approach. Strangely enough, the purported author of SOA's Obituary (Anne), wrote a great blog entry on how NOT to do REST style SOA here.
My conclusion:
SOA is architecture that is focused on services as the abstract action boundary between (business) needs and (business) capabilities. As such, the form of architecture known as SOA that captures that blueprint and relates it to business services is not dead and will survive well into the next decade.
SOA IS NOT DEAD!
I must correct myself. Paul Krill is not implying anything. He is merely quoting Anne. My bad.
ReplyDeleteDuane, I agree with the title of your comment and the statement about architecture.
ReplyDeleteAnne sees things very judiciusly and she is right. Since the inception of the micro environment in our world, a project lasting more than 30 days is defferred or canceled because does not bring revenue quick enough.
We have throwon out logic with the bath water and we resort to developments that are unstable and unpredictable. If you are a non-believer, look at how many times in a development we grab unstable and unsecured data? We no longer have data-driven environment that fluid relationships abound and provide us with correct information securely.
I have been there too long to see that we live in a catastrophic world. Our architecture is to thin layered that we invite disaster to strike.
SOA as an architectural concept will NEVER DIE. Perhaps the buzzword of 'SOA' will no longer be a buzzword for IT and business to fish for funding. But that's about as far as it will go - ever.
ReplyDeleteOliver