Service-Oriented Architecture Service-Oriented Architecture, or SOA, is the newest acronym to become a buzzword among developers, IT Managers, and CTOs. It seems that everyone is talking about making an SOA and how much it will improve their operations, yet most people are hard-pressed to define not only what an SOA is, but also to quantify what specific value it might provide to their organizations. Many simply assert that their SOA architecture comprises a group of Web Services through which they can expose business logic over the Internet. A service-oriented architecture is comprised of a number of different services that can be consumed by any number of clients. The only assumption made by either party is that communication takes the form of a well-defined and strictly enforced contract. | " |
Service providers are components that provide a service that can be used by any number of clients. The only requirement for the utilization of the service is strict adherence to the provider's published interface.
| " |
The purpose of this article is to describe a Service-Oriented Architecture (SOA) in terms of the IT industry. Unfortunately, the term SOA doesn't really have a formal definition. In fact, many people believe that SOA means you have several Web Services exposed to clients. Although this is not necessarily wrong, it's not the whole requirement either. An SOA is much more than mere Web Services. In fact, Web Services are not a requirement for implementing an SOA; an SOA is about architectural refinement rather than the implementation of one specific technology. This means that an SOA converts your architecture from isolated systems into black box services that can be reused without modification. To fully implement an SOA, you must move from a monolithic application development model to a publisher/consumer application development model. Developing software to utilize formal contracts and become autonomous removes the dependence on elements outside of the formal contract. Companies developing applications around a publisher/consumer model will find themselves with a flexible architecture, one that is able to provide a large amount of functionality without compromising the core of the system. The creation of explicit contracts between consumers and providers facilitates a lot of flexibility when accessing the services. Because providers are not directly tied to consumers, contracts allow the service provider to service any consumer, as long as the consumer accesses the service using the defined contract. Service-Oriented Architectures are Nothing New SOAs are nothing new. The concepts behind SOAs, providers and consumers, have been around for many years. Most recently, CORBA, DCOM, and RPC-style distributed middleware have been the basis for SOA implementations. | & | | 
By: Griffin Caprio Griffin is an independent consultant in the Chicago metropolitan area. He has been helping deploy .NET solutions for the past three years for clients ranging from small startups to large, Fortune 500 companies. He is an active developer on several OSS .NET projects, including .NET Mock Objects and Spring.Net. He has never turned down a game of foosball. Any questions or comments can be directed to the address found above.
| Fast Facts | | A service-oriented architecture is comprised of a number of different services that can be consumed by any number of clients. The only assumption made by either party is that communication takes the form of a well-defined and strictly enforced contract. | |
|