An Introduction to Service-Oriented Architecture : Page 3
An SOA is much more than mere Web services. Get a straightforward explanation of everybody's favorite tech buzzword du jour and find out how you can implement SOA in your organization with a simple, real world example and guidelines.
by Griffin Caprio
Jun 8, 2005
Page 3 of 3
SOA Do's and Don'ts
This article gives a brief overview of what an SOA is and also examined a small example of a SOA in use today. You might be asking yourself if an SOA is right for your environment and, if so, how you can implement it.
Here are some guidelines to keep in mind when architecting your system in order to make it an SOA-friendly environment:
Don't concentrate on the implementation specifics of who or what will use your system. This means that you shouldn't look too much at internal clients or external clients. Settle on extensible options, while keeping your system defensive on the type of data it consumes.
Do base interactions on well-defined contractual formats, like XML schemas.
Don't make assumptions about who or what will be using your service. Your system could be originally used from a Web site, but could easily be required to be accessible from a Windows client or Web service.
Do think about your software as autonomous and stateless. Base service contracts on accepting everything needed to fulfill a service request.
Don't believe that you can think of every possible use for your system. Future requirements could bring new interactions. For example, don't create one service to provide a filtered view of certain data. Instead, create two services, one to provide the data, and the other to accept the date, apply the filter and return the filtered results.
Do separate your application into tiers. This enables the creation of services at any tier. For example, tiers allow you to expose business logic, as well as data, as services.
Don't think that the initial UI used to interact with your system is the only way that you will want to interact with your system. If you have a Web application, don't think of the whole system in terms of the Web site, but as a individual system, with one possible front end being the Web site.
Building an SOA is not an easy task. It takes a lot of time and patience to be able to make sound and consistent decisions that keep the larger SOA vision paramount. Architects and developers must resist the urge to circumvent the provider and consumer model in favor of quicker, short term fixes.
Team members must also migrate existing service-based thinking from purely external interactions to other internal aspects of development, including component assembly and interface design. Applying the consumer and provider model to these constructs is complex, and is the subject of future articles.
Above all, remember to build flexibility into your software. This does not mean building in hooks and extension points into your applications. Rather, reduce the dependencies and assumptions of your applications. Reducing the dependencies of your application on current requirements increases the possibility that your software can be used outside of the possibly narrow scope originally defined.
Griffin Caprio is an independent consultant in the Chicago metro area who has helped clients deploy .NET solutions for the past three years. His clients include small startups to large, Fortune 500 companies. He is an active developer on several OSS .NET projects, and he has never turned down a game of foosball.