Trajectory Service Design Pattern

From Earth Science Information Partners (ESIP)
Revision as of 07:13, June 16, 2006 by Erin Robinson (ERobinson) (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Page in progress

Name

Trajectory Service Design Pattern ===Synopsis=== - brief description (aka "intent").

  • Trajectory service should provide forward/backward trajectories To create a flexible, compound service

===Context=== - description of a problem which the pattern addresses (aka "motivation").

  • Air pollution sources impact their atmospheric environment that may be thousands of kilometers away. Thus, due to atmospheric mixing the pollutant concentration at any given receptor location is contributed from many different sources, and the source receptor relationship is difficult to quantify. Air mass history,i.e. trajectories, provide simple diagnostics tool to indicate the pollution source regions.

===Forces=== - considerations which "push" the designer towards using the pattern. ===Solution=== - addresses the general problem of which the context section is an example.

  • Modular components, web services:
    • Wind Data Access, Trajectory Calculator, Trajectory Aggregator, Trajectory Portrayal
  • Service Chaining
  • Service Execution

Consequences

  • the implications, good or otherwise, of using the pattern.

===Implementation=== - issues to be aware of in implementing an instance of the pattern.

  • Redundancy Caching...
  • Collaboration
  • Compound Service Persistence

Examples

  • preferably at least 3 different ones.

Related patterns

  • Wind Data Access, Trajectory Calculator, Trajectory Aggregator, Trajectory Portrayal

e.g. alternatives, or ones which are often used together with the pattern being described.