SOA

Digg This!

Page 2 of 4   « previous page   next page »

Service Deployment
The implementation stage brings with it the joys of installing and configuring distributed components, service interfaces, and any associated middleware products onto production servers. Typical issues arising during this phase include:

• How will services be distributed?
• Is the infrastructure adequate to fulfill the processing requirements of all services?
• How will the introduction of new services affect existing services and applications?
• How should services used by multiple solutions be positioned and deployed?
• How will the introduction of any required middleware affect the existing environment?
• Do these services introduce new versions of service descriptions that will need to be deployed alongside existing versions?
• What security settings and accounts are required?
• How will service pools be maintained to accommodate planned or unforeseen scalability requirements?
• How will encapsulated legacy systems with performance or reliability limitations be maintained and monitored?

Service Administration
Once services are deployed, standard application management issues come to the forefront. These are similar in nature to the administration concerns for distributed, component-based applications, except that they may also apply to services as a whole (as opposed to services belonging to a specific application environment). Issues frequently include the following.

• How will service usage be monitored?
• What form of version control will be used to manage service-description documents?
• How will messages be traced and managed?
• How will performance bottlenecks be detected?

Note that though SOA governance comes into effect at this stage, it is a critical part of service-oriented solution delivery that must be planned for well ahead of time.

SOA Delivery Strategies
These life-cycle stages represent a simple, sequential path to building individual services. We now need to organize them into a process that can:

• accommodate our preferences with regards to which types of service layers we want to deliver
• coordinate the delivery of application, business, and process services
• support a transition toward a standardized SOA while helping us fulfill immediate, project-specific requirements

The last item on the above list poses the greatest challenge. The success of SOA within an enterprise is generally dependent on the extent to which it is standardized when it is phased into business and application domains. However, the success of a project delivering a service-oriented solution is generally measured by the extent to which the solution fulfills expected requirements within a given budget and timeline.

To address this problem, we need a strategy. This strategy must be based on an organization's priorities in order to establish the correct balance between the delivery of long-term migration goals with the fulfillment of short-term requirements.

The top-down, bottom-up, and agile strategies we introduced at the beginning of this article each address this problem with differing priorities and practical considerations. The following three sections provide process descriptions and explore the pros and cons of each approach.

The Top-Down Strategy
This is very much an "analysis first" approach that requires not only business processes to become service-oriented, it also promotes the creation (or realignment) of an organization's overall business model. This process is therefore closely tied to or derived from an organization's existing business logic, and it commonly results in the creation of numerous reusable business and application services. The top-down approach will typically contain some or all of the steps illustrated and described in Figure 2. Note that this process assumes that business requirements have already been collected and defined.

Step 1: Define relevant enterprise-wide ontology
Part of what an ontology establishes is a classification of information sets processed by an organization. This results in a common vocabulary, as well as a definition of how these information sets relate to each other. Larger organizations with multiple business areas can have several ontologies, each governing a specific division of business. It is expected that these specialized ontologies all align to support an enterprise-wide ontology.

If such a business vocabulary does not yet exist for whatever information sets a solution is required to work with, then this step requires that it be defined. A significant amount of up-front information gathering and high-level business analysis effort may therefore be required.

Step 2: Align relevant business models (including entity models) with new or revised ontology
Once the ontology is established, existing business models may need to be adjusted (or even created) in order to properly represent the vocabulary provided by the ontology in business modeling terms. Entity models in particular are of importance, as they can later be used as the basis for entity-centric business services.

Steps 3 and 4: Perform service-oriented analysis and service-oriented design
The aforementioned service-oriented analysis and service-oriented design processes are completed.

Step 5: Develop the required services
Services are developed according to their respective design specifications and the service descriptions created in Step 4.

Page 2 of 4   « previous page   next page »