|
The article does a good job of explaining some SOA principles such as
architecting services that are loosely coupled and without any presentation code. However it is important to remember that Web services are only one way of deploying service oriented solutions. Here are a few other principles to remember when architecting your SOA solution.
Services should be protocol independent. This allows the service to be accessed in multiple ways. In fact, the way the service is used should be a deployment decision rather than a design decision. This allows the developer to build the business logic (service) free from any other code, including architecture, presentation, or persistence code. This keeps the business logic very clean. At deployment time the SOA framework makes this service available, perhaps as a Web service.
Services should also be coarse-grained. The client should be able to make a single request to the service and have the service accomplish the task at hand and return the response. If you find yourself making multiple calls to the service for the same process, perhaps it is time to refactor your service to accomplish more with a single call.
Just as object-oriented programming (OOP) was a big boost to the developer, so too is service-oriented programming becoming an important methodology for building enterprise applications. SOP builds upon OOP principles and adds "dynamicity" to the development and deployment, allowing design decisions to be done at design time, development decisions at development time, and deployment decisions at deployment time.
|
