Service Oriented Architecture SOA- is another strategic milestone in the enterprise architecture world. Many enterprises fuel the myth that surmount the today s SOA mantra. Is it real or hypothetic? Are CTOs and CIOs responsible for this hype? The questions remain unanswered.
Most of the time, one does not look past his previous attempts towards the solutions he delivered and learn from his drawbacks. Enterprises bet on SOA, but how do you implement a successful SOA today in your company? There are some adhoc SOA implementations available they may not potentially transform the way IT and businesses colloborate. But, do these implementations reap the real benefits of a SOA? This is just a question of time. Managing services, processes, and IT assets is always a challenge for huge enterprises due to its heterogenous nature. Multiple technologies J2EE, .NET, Legacy, and so forth- and disparate applications SAP, IBM, Oracle, and so on- rule an enterprise, leading to integration chaos. Web services are becoming vogue for implementing Enterprise SOA. Also, Web services help in overcoming the integration complexities faced by traditional Enterprise Application Integration EAI- approach. The rationale behind this proposal is to leverage an enterprise s existing expertise in building solutions and align to SOA principles, which could potentially help to overcome traditional problems which require state-of-the-art integration. The W3C Web Services Architecture Working Group defines SOA as a form of distributed systems architecture that is typically characterized by the following properties: Logical view: The service is an abstracted, logical view of actual programs, databases, business processes, and the like, defined in terms of what it does, typically carrying out a business-level operation. Message orientation: The service is formally defined in terms of the messages exchanged between provider agents and requester agents, and not the properties of the agents themselves. The internal structure of an agent?including features such as its implementation language, process structure, and even database structure?are deliberately abstracted away in the SOA: By using the SOA discipline, one does not and should not need to know how an agent implementing a service is constructed. A key benefit of this concerns so-called legacy systems. By avoiding any knowledge of the internal structure of an agent, one can incorporate any software component or application that can be wrapped in message handling code that allows it to adhere to the formal service definition. Description orientation: A service is described by machine-processable meta data. The description supports the public nature of the SOA: Only those details that are exposed to the public and important for the use of the service should be included in the description. The semantics of a service should be documented, either directly or indirectly, by its description. Granularity: Services tend to use a small number of operations with relatively large and complex messages. Network orientation: Services tend to be oriented toward use over a network, though this is not an absolute requirement. Platform neutral: Messages are sent in a platform-neutral, standardized format delivered through the interfaces. XML is the most obvious format that meets this constraint. Source and full article: www.developer.coma>