July 6, 2010 by huionn
What is SOA?
In computing, a service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration. A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains.
SOA also generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well understood, well defined interface to access them. XML is commonly used for interfacing with SOA services, though this is not required.
SOA defines how to integrate widely disparate applications for a world that is Web based and uses multiple implementation platforms. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such an SOA implementation.
Service-orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.
Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the overall burden of IT on an organization. It accomplishes this by positioning services as the primary means through which solution logic is represented. SOA supports service-orientation in the realization of the strategic goals associated with service-oriented computing.
As a form of technology architecture, an SOA implementation can consist of a combination of technologies, products, APIs, supporting infrastructure extensions, and various other parts. The actual face of a deployed service-oriented architecture is unique within each enterprise; however it is typified by the introduction of new technologies and platforms that specifically support the creation, execution, and evolution of service-oriented solutions. As a result, building a technology architecture around the service-oriented architectural model establishes an environment suitable for solution logic that has been designed in compliance with service-orientation design principles.
Hmm… seem like SOA is the Holy Grail to all software development problems.
There is a controversial blog about SOA: SOA is Dead; Long Live Services
SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”.
Once thought to be the savior of IT, SOA instead turned into a great failed experiment—at least for most organizations. SOA was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever. The people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives.
It’s time to accept reality. SOA fatigue has turned into SOA disillusionment. Business people no longer believe that SOA will deliver spectacular benefits. “SOA” has become a bad word. It must be removed from our vocabulary.
I do agree at it. From the books I read, SOA is hard. It is even harder than the problems it solves. However, service-orientation consists of good design principles to promote loose coupling. Without distribution as implied by SOA, the SOA design principles are fundamentally similar to modular design –
Modular design is an approach that subdivides a system into smaller parts (modules) that can be independently created and then used in different systems to drive multiple functionalities. Besides reduction in cost (due to lesser customization, and less learning time), and flexibility in design, modularity offers other benefits such as augmentation (adding new solution by merely plugging in a new module), and exclusion.
Good read from InfoQ: Learnings from Five Years as a Skype Architect
Buzzwords are dangerous
Every now and then somebody comes up with a great way of building software, invents a catchy name for it and before you know it turns up on PowerPoint decks everywhere. Unfortunately most of these ideas are quite complicated and very few of them are practical. Things like J2EE, CORBA, SOA are not designed to solve everyday problems software engineers face every day. Oh, they sometimes manage to do that but it’s accidental.
We have had this problem repeatedly at Skype and have been reasonably successful in dealing with it. Another organization we heard of had a rather different experience, though. At some point we started seeing a lot of applicants from a big software house that had just recently seen it’s entire engineering management replaced.
One of the expats told the story.
Apparently the top management had certain issues with the amount of time their main product took to customize and had decided, based on what some consultants told them, that going all cloud- and SOA based would help them. So they started talking to the engineering leads who answered with blank stares, a flurry of Dilbert strips and long tirades about how this is all a huge lake of snake oil. After a while the inevitable happened, the management got fed up with being pictured as morons (the consultant had been an expensive one) and as nobody seemed to be solving the initial problem they had the next logical step was taken. Get rid of the clearly incompetent bunch of naysayers who offer insults instead of constructive cooperation. The company is probably never going to recover.
SOA is at the slope of enlightenment…