Robust .NET TreeList and ListView Header
More Articles SOA Explained An introduction to SOA The latest best practice for enterprise level software is known as SOA. It has been a hot topic for a couple years now so I decided to write an article to get some coverage on what exactly is SOA. This article will attempt to explain the services, platform and basis that make up SOA architecture. SOA architecture is an evolved form of distributed computing based around the request/reply paradigm for synchronuous and asynchronous applications. Functions are modularized for an application's business logic or individual functions and present as services for consumer and client apps. The key to these services is their loosely couple functionality. The service interface is independant of the implementation. Developers or system integrators can build applications by composing one or more serivces without knowing the service's underlying implementations. As an example, a service can be implmented either in .net or J2EE with the consuming aplication can be a service on a completely different platform using any number of languages. SOA is not a langauge or a set of tools. Rather is a methodology of putting disperate services together to form something more useful. Many characteristics are common to SOA architectures: 1. Interfaces descrbied in XML that can be discovered through WSDL querying. 2. SOA services may be maintained in a central directory listing called Universal Description Definition and Integration (UDDI). 3. SOA Services have Quality of service levels associated with them. Key elements of QoS are authentication, reliable messaging and policies that govern whom can invoke the service and under what context. 4. XML messages (based on XSD Schema) between services. Consumer / Provider communications pass messages in a mostly non-blocking way. 5. Message based communications that may Message Communications and QoS SOA also defines messages architecture in layers. Messages may be inspected for extra routing or security information during transmition. This allows for high-end enterprise messaging where for instance you can inject QoS guidelines for high priority messages. Messages may also have security information injected An examples of QoS Lets say you have service provider P who is subscribed to by service consumer C. P is hosted deep in a highly secure internal server from an enterprise information provider. To route messages into that provider from the edge firewalls to the internal server, a message has to have security information added to it before being passed along. Once that messages has the proper security tokens added, it is passed into the internal server where it is processed. After processing, the message is then passed back out to the edge device where the security information is removed and the message is passed back to the initial consumer. So why should we move to SOA? One of the principle drivers behind the move to SOA is the number of disperate systems employed by enterprises today. Some existing applications are used to run current business processes, so starting from scratch to build new infrastructure isn't an option. Enterprises should quickly respond to business changes with agility; leverage existing investments in applications and application infrastructure to address newer business requirements; support new channels of interactions with customers, partners, and suppliers; and feature an architecture that supports organic business. SOA with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services in a granular fashion to address the new business requirements, provides the option to make the services consumable across different channels, and exposes the existing enterprise and legacy applications as services, thereby safeguarding existing IT infrastructure investments.
Version Date Change Download Buy