|
|
Re: Top 10 Reasons SOA Projects Fail
|
Posted: Aug 5, 2008 2:55 PM
|
|
The biggest problem with the term SOA is the fact that it is a valueless term. It doesn't say anything about what matters to those who might implement one.
SOA includes the word "architecture" to make its use independent of technology. However, in the end, it is specific technologies that help make an SOA successful.
You have to understand why idempotent interfaces are key. You have to understand why distributed systems need things like leasing and transactions for effect resource management. You need to include explicit fail over strategies for every remote entity that participates in the system. You need to understand how authentication and authorization are best done as detached, pluggable parts of the system.
Some distributed system technologies include all of these things as integral parts of what they provide. Many products and technologies are but one part of a more complex system architecture.
The team of people implementing an SOA need to understand how each technology interfaces to each other so that the impact of those interfaces can be part of the architecture and design processes.
My typical mantra is that if you are using Java for your SOA services, you should be using Jini for your technology of choice to interface services that talk to each other. I say this because Jini exploits the power of Java's mobile code model to keep versioning issues minimized. Smart proxies can be deployed to work around versioning issues that would typically make your service support multiple interfaces. A single proxy object can be sent out with multiple interfaces supported and it can do conversions that allow a single service interface to be supported with the old clients utilizing the smart proxy as the versioning compatibility entity.
There are transport/communications technologies such as the low level FTP and HTTP kinds. There are higher level technologies for RPC such as Corba and RMI-IIOP (and RMI-JRMP) that are binary oriented transports. Then there is marshalling based normalization such as WS-X that include a plethora of "semantics" tied to the otherwise "neutral" content.
If you look around at all these various technologies, there are lots of partial players. Technologies like J2EE and .Net attempt to broaden the underlying technologies into particular types of markets by having support for very specific types of solutions integrated into the "platform" that they represent.
Frameworks such as Spring, provide a style, but not really a feature set of "technologies" that might make distributed systems work (directly).
My Jini mantra comes from the fact that Jini has support for all the things that I consider integral parts of good SOA as parts of the platform. They all work together, share a common model, similar issues for each service in lifecycle, interface, security etc. So, I think its more likely that you could teach a team of people how to be effective Jini developers then to teach them how to use the plethora of technologies and packages that you need to integrate into a more "heterogeneous" system.
Alas, I know that most people wrote of Jini a long time ago because of the old licensing issues. It's been open source under apache for more than 2 years now, so it is "free" for the taking.
It's interesting to see how people are experiencing SOA. I tend to think the failures are really about poor choices and bad execution rather than about SOA being a problem child.
SOA is possible to do, but you have to understand the 10 fallacies of distributed systems and be able to consider each technology you wish to deploy in light of those, and decide whether that technology is appropriate, and if not how to make the appropriate change in architecture, expectation or technology.
|
|
Previous Topic
