Service-oriented analysis seeks to answer:
- What services should comprise the system?
- What logic should each service contain?
- What are the physical service interface definitions for each service?
- What characteristics of a service-oriented architecture will the system support?
- What specific standards and technologies will be used to implement the services?
A service-oriented analysis is comprised of the following tasks, which are addressed in roughly the following sequence:
- Define a set of service operation candidates
- Group the operation candidates into logical contexts to define service candidates
- Establish service responsibilities so as to reconcile overlaps and gaps
- Identify opportunities for reuse
- Define any known service composition models
Review business requirements that are in the scope of a service-oriented solution.
Not all business requirements can be satisfied in their entirety by a service-oriented solution. The first step of a service-oriented analysis is to identify those requirements that will be subject to analysis.
For example: The business requirements for a project define a use case wherein a user retrieves information from the proposed system and uses this to mail an information package to a customer. In this requirement, the scope of the service-oriented solution extends only to the information retrieval itself. The user interface that displays the information to the user is not considered in the service-oriented analysis.
Identify existing automated solutions and data that may be used to support a service-oriented solution to the business requirements.
Most useful service-oriented solutions at CRI will need to access data and business logic that already resides in existing automated systems. Once the in-scope requirements are known, the next step is to identify the programs and database tables in the CRI system that may be needed to support the service-oriented solution. Where significant useful business and data access logic resides in existing programs, this logic may be made available to the service-oriented solution by service-enabling the programs involved. Similarly, data in existing database tables may need to be encapsulated in database views or stored procedures to provide the service-oriented solution with an appropriate logical access path to the physical relational data structures.
For example: The business requirements to be satisfied by a service-oriented solution define a use case wherein a user updates information in the existing system. The existing system already contains a COBOL program that performs the necessary update. The business rules for the update are substantial, so the analysis should encompass service-enabling the program in question. In another use case, the user must retrieve information that resides in the existing system. The business rules for this access are negligible, so the analysis should encompass encapsulation of the data in a database view.
Break down the business process flows documented in the requirements into a series of process steps.
Many business requirements will define use cases that outline a business process flow. The individual process steps in each flow should be isolated and compared with one another to discover commonalities.
For example: The business requirements to be satisfied by a service-oriented solution define a use case wherein a user creates a user profile, associates on or more accounts with the profile, and sends a request to an administrator to have the associations approved. In another use case, a user accesses an existing user profile, associates one or more accounts, and sends an approval request to the administrator. As part of the service-oriented analysis, four process steps should be identified -- create a new user profile, access an existing user profile, associate accounts, and send approval request.
Eliminate process steps that cannot be automated or are implemented in existing automated solutions that cannot be encapsulated.
Not all business requirements can be satisfied in their entirety by an automated system. Not all existing systems are accessible to the service-oriented solution. Process steps that stem from such cases are outside the scope of a service-oriented solution.
For example: The business requirements for a project define a use case wherein a user retrieves information from the proposed system and uses this to mail an information package to a customer. In this requirement, the scope of the service-oriented extends only to the information retrieval itself, not to the process step of physically mailing the information package. Therefore, only the information retrieval process step would be considered in the service-oriented analysis.
Identify reusable business logic and condense process steps that use this logic.
Some process steps will necessitate the same or similar business logic. To prevent duplication and encourage future reuse, process steps containing such reusable business logic should be combined. It will often be necessary to generalize the process steps to do this.
For example: The business requirements for a project include two use cases that contain a similar process step. In one, the system will send notification to a user when an account association is approved. In the other, the system will send notification to an administrator when the user requests approval of an account association. Rather than defining two process steps (send approval notice and send approval request notice) the service-oriented analysis should generalize these into a single process step (send notice) that can be reused in both cases.
The final list of process steps are the service operation candidates for the service-oriented solution.
The service-oriented analysis steps to this point should yield a more-or-less comprehensive list of unique process steps -- actions that the automated system must support. These are candidates for consideration as service operations in subsequent steps of the service-oriented analysis and design.
For example: The service operation candidates identified in an analysis of the business requirements for account approval presented in the examples so far would include:
- Create a new user profile
- Retrieve an existing user profile
- Associate an account to a user profile
- Approve association of an account to a user profile
- Send a notice
Group together those service operation candidates that operate in the same logical context related to a business entity.
Typically, a step in a business process flow will operate on a single business entity or a small group of related entities. The service operation candidates derived from process steps that operate on the same business entity can be said to operate in the logical context of that entity. These service operation candidates should be grouped together as the the first step of defining service candidates in the service-oriented analysis.
For example: An analysis of the business requirements for account approval presented in the examples so far should group the following service operation candidates together since they all operate in the context of a user profile:
- Create a new user profile
- Retrieve an existing user profile
- Associate an account to a user profile
- Approve association of an account to a user profile
Some steps in a business process flow will not operate on a single type of business entity but can instead apply to a number of business entity types. The service operation candidates derived from steps within the same or similar business process flows can be said to operate in the logical context of that flow. These service operation candidates should be grouped together as the the next step of defining service candidates in the service-oriented analysis.
For example: An analysis of the business requirements for account approval presented in the examples so far should group the following service operation candidate in the context of a process flow:
- Send a notice
Once all service operation candidates have been grouped into a logical context, those logical contexts can be considered to be service candidates. These will be fully defined and refined in the service-oriented design process.
For example: The service candidates and their associated service operation candidates for the account approval process presented in the examples so far are:
- User Profile Service
- Create a new user profile
- Retrieve an existing user profile
- Associate an account to a user profile
- Approve association of an account to a user profile
- Notification Service
- Send a notice
Apply the service-oriented principles of autonomy, loose coupling, and statelessness to refine the list of service operation candidates for each service candidate.
Once the preliminary service candidates have been identified, the analyst should establish clear boundaries between service responsibilities according to the architectural principle of separation of concerns and its related service-oriented principles. Service operation candidates that do not really fit within the responsibilities of a given service should be moved to another (perhaps new) service candidate. In particular, this process tends to identify service operation candidates initially associated with a business entity service that are actually more suited to a business process service.
For example: The initial list of service candidates for a service-oriented solution includes a service candidate that groups operation candidates that operate in the context of the account business entity. The service-oriented analysis establishes that this service candidate should have responsibility for the creation and maintenance of accounts. One of this service's operation candidates, "Notify account of approval", describes an activity that is superficially related to the account business entity, but does not really fit within the "creation and maintenance" boundary. This operation candidate may be better suited for inclusion in a business process service candidate dealing with notifications.
Identify Reuse Opportunities
Apply the service-oriented principles of reusability and abstraction to identify services that can be expanded or combined for reuse in the broader service-oriented solution.
Once the preliminary service candidates and their responsibilities have been identified, the analyst should consider whether adding operations to services, extracting services, or combining services would make the collection of services more reusable in the overall service-oriented solution. In particular, the business requirements for a service-oriented solution tend to omit certain kinds of useful functions related to business entities because these functions are not immediately envisioned in the business process flow. For example, the business requirements may include a use case for retrieving a list of accounts, but not for retrieving all information on a selected account. Adding operation candidates for such functions when a service is initially designed will make it more likely that the service can be readily adapted to future requirements.
For example: The business requirements for a service-oriented solution define use cases that relate to a bank business entity. Most of the initial service operation candidates in this business entity context could apply to any type of financial institution. The service-oriented analysis might generalize the bank business entity as a type of financial institution, perhaps providing service operation candidates to handle activities that are exclusive to banks.
Define Service Composition Models
Apply the service-oriented principles of composability and discoverability to identify services that can be composed wholly or in part from other services.
In establishing clear service boundaries and identifying opportunities for reuse, the service-oriented analysis will identify a number of services that can be used by other services. The relationships between these services and their operations should be identified and documented.
For example: The business requirements for a service-oriented solution specify that when an account is opened, the system will notify the account owner. The business entity service candidate responsible for accounts defines an operation candidate to open the account, which will invoke a service operation of the process flow service candidate responsible for notifications. This relationship should be documented as part of the service-oriented analysis.
Service-Oriented Design Process
Working from the service-oriented analysis, service-oriented design is comprised of the following tasks, which are typically addressed concurrently in iterations of increasing detail:
- Define abstract service interface definitions
- Define abstract service compositions
- Apply service-orientation principles and standards
Begin the service interface definition process with entity service candidates and progress to process service candidates.
In general, business entity services tend to be more reusable than business process services. Designing the most reusable services first will ease the design of the more process-specific services, particularly when designing composite services.
Define the input and output messages for each service operation.
Synchronous service operations will typically expect a single input (request) message type and will return one or more output (reply) messages, depending on the processing outcome.
The input and output messages used in each service operation should be defined in the abstract.
For example: A service operation to lookup an account might expect a request message containing the account selection criteria. If the account can be found, the operation will reply with a message containing the account information. If the account is not found, the operation will reply with a message containing error information.
Define the preconditions, postconditions, processing logic and expected exceptions for each service operation.
A service operation will typically depend a set of existing states in the system. These are the preconditions for the operation. An operation may produce changes to the state of the system. These are the postconditions for the operation. By definition, an operation performs some processing logic, which will either result in success or some failure condition (an exception).
The operation's preconditions, processing logic and postconditions for all success and failure cases should be defined and documented in the abstract.
For example: The design of a service operation to add an account entity to the system might define the following:
- Preconditions
- At least one account representative entity exists in the system database
- Postconditions
- On success: the new account entity will exist in the system database
- On failure: the system state will be unchanged
- Processing logic
- Verify that the input account representative exists in the system database
- Validate that the input account name and address information is well-formed
- Verify that the input city, state and ZIP code are consistent with the national address database
- Add the account to the system database
- Exceptions
- The input account representative cannot be found
- The system database is not available to lookup the input account representative
- The input account name or address information is not well-formed
- The input city, state and ZIP code are inconsistent with the national address database
- The national address database is not available to verify the input city, state and ZIP code
- The attempt to add the account to the system database fails
Each input or output message will consist of a number of data structures and elements. These should be defined and documented in the abstract.
For example: The design of a service operation to add an account entity to the system might define the following:
- Add account request (input)
- account representative ID - specifies the account representative to be associated with the account
- first name, middle initial, last name - the primary name associated with the account
- address, city, state, ZIP code - the primary address associated with the account
- Add account success reply (output)
- account ID - the unique identifier of the newly created account
- Standard exception reply (output)
- error ID - the unique identifier of the error message
- error description - a short text description of the error condition
Define the process flow of all service compositions.
The process model documented in the service-oriented analysis will identify a number of services that can be used by other services. The process flow relationships between these services and their operations should be defined in detail. It may be necessary to amend service, operation, message or processing logic definitions to facilitate the process flow.
For example: The design of a service operation to add an account entity to the system requires invocation of another service operation that looks up the input city and state for a given ZIP code in the national address database. As part of the service-oriented design, the designer reviews the service operations to see if additional operations or messages are needed. This reveals the need for additional processing logic and messages to support to looking up the ZIP code for a given city and state.
Review the service operation definitions for any transaction or exception handling that may be required by the composition.
The process of detailing the service compositions will generally reveal additional requirements for transaction and error handling. These additional features should be detailed and documented.
For example:
The design of a service operation to add an account entity to the system requires invocation of a service operation that looks up the input city and state for a given ZIP code in the national address database. As part of the service-oriented design, the designer reviews the service operations to see if additional transaction or error handling is needed. This reveals the need for additional error handling in the "add account" operation to distinguish between cases where the ZIP code is invalid and cases where the "lookup ZIP code" service is unavailable.
Apply SOA Principles and Standards
Apply business ontology and service-oriented naming standards to name and describe each service and service operation.
The service-oriented design process to this point will yield a list of service and operation definitions at an abstract level. The business entities or business processes identified in these definitions should be given final names and descriptions with reference to standard business terminology and technical naming standards.
Apply business ontology and service-oriented naming standards to name and describe each message.
The service-oriented design process to this point will yield a list of messages at an abstract level. The business entities identified in these definitions should be given final names and descriptions with reference to standard business terminology and technical naming standards.
Apply business ontology, service-oriented naming standards and data standards to name, describe and type each data structure and element.
The service-oriented design process to this point will yield a list of data structures and elements at an abstract level. The business entities identified in these definitions should be given final names and descriptions with reference to standard business terminology, technical naming standards and data type standards.
References
Ten Ways to Identify Services
"SOA: Principles of Service Design" by Thomas Erl (Prentice Hall, 2007)
No comments:
Post a Comment