SOA Best Practice

Service Oriented Architecture SOA Best Practice

The Cape Clear Developer web site provides many resources to assist you throughout the lifecycle of your SOA projects. There are many articles of use to SOA architects as well as developers. This page introduces many of these articles and places them within the context of your SOA projects.

Getting Started
If you’re just getting started, read our Concepts article for a brief introduction to Service-Oriented Architecture and how you can start building services using the Enterprise Service Bus. Still need to be convinced? Read ESB and BPEL: Changing the Rules of Integration to see how your SOA is going to change the way you approach integration projects. Now that you’re convinced you need to build a SOA, be careful about those in your organization tempted to stick with the old practices, but apply a SOA badge. In short, Beware of Shortcuts on the Road to a Service-Oriented Architecture.

IT Governance has become increasingly important as should be an important part of your SOA strategy. Governance: the new word for Best Practice explains the needs for governance and its relationship to the Cape Clear product set.

Design
The most visible aspect of the services in your SOA is the interface. A significant part of the design will culminate in the creation of these interfaces. The general issues such as granularity and loose coupling have already been introduced in the Concepts article mentioned above. Some concrete examples of interface design, and in particular the influence of BPEL on your interfaces, are presented in How BPEL and SOA Are Changing Web Services Development.

The requirement to deploy new versions of a service is something that needs to be considered as part of the design process. A strategy for versioning Web services is described in Service versioning in a SOA. The issue of achieving compatible interfaces using XML Schemas is addressed in Avoid XML Schema Wildcards For Web Service Interfaces. Each component within the ESB performs a specific role. Ensuring that these components are used in the appropriate way is an important part of the design. Spot the mistakes - Two things you shouldn’t do with BPEL illustrates this point with a simple BPEL code snippet.

Integrate
Much of the functionality in your SOA will be provided by the existing applications. So the initial tasks become a case of "Expose the function currently provided by application X as a Web service". The ESB is particularly powerful in assisting you in doing this. It provides connections to the transports your existing applications use and tools necessary to transform existing message formats to XML. See the Cape Clear ESB Overview for a brief description of the features available to you that assist in this.

Develop
You will find many working examples of the kind of services that you will be developing in our demos and tutorials section. The testing of your SOA in parallel with development is essential. Performance Testing in a SOA outlines the various kinds of testing required.

Deploy
Before going into deployment, the services that make up your SOA need to be able to guarantee high levels of quality of service. The ESB provides many features to facilitate this, but you must ensure that your services have been designed and developed in order to take advantage of these advanced features. Designing Mission Critical Applications presents many recommendations on how you can ensure that your services are Reliable, Available, Scalable and offer high Performance. Services must also be secure; the security capabilities offered by the Cape Clear ESB are described in Security in the Cape Clear ESB. The WS-Security tutorial allows you to see security in action and explains the specifics of applying WS-Security to your services.

Source: http://developer.capeclear.com/soa