|
Analyze the candidate services and their candidate tasks, and model the physical (to be implemented) services resulting from that analysis.
This represents a "refinement" process. During this step a more logical partitioning of services that what is present
in the candidate model may be found.
Also, for utility service candidates, ensure the granularity of the logic partitions represented by the task candidates
are generic and reusable.
|
Model the resulting service tasks.
The final list of service tasks, and their allocation to services defined in the previous step, reflects potentially
new design decisions, and may not result in the same structure shown in the candidate model.
Generally, the tasks defined in this step will not be implemented with individual messages. All of a
service's tasks identified in this step will usually be accessed by sending a single, generic, parameter-driven
message.
|
Standardize task names by reviewing the data structures in the relevant XML message schemas.
|
