Design decisions

From SIMSTADT
Jump to: navigation, search

Contents

[edit] Will we develop one system or several systems?

Problem
Given such diverse requirements as developing and assessing new simulation algorithms (by scientists), performing simulation studies (by engineers), and access simulations or simulation results (by lay persons), we have to decide if we want to develop - from the user's point of view - one system or several.

Constraints

  1. The decision is mainly influenced by answering the question: Which feature for which user group do we like to offer when?
  2. What are our capabilities for software development?
  3. Will the coordination of software development get more difficult or more easy?

Assumptions
TBD

Considered Alternatives

  1. Develop one integrated system for all (potential) users, probably with different data and user interfaces
  2. Let us concentrate on the development of a testbed-like software for scientists first and, in a second phase, make some of these available for the other user groups in a dedicated system.

Decision
TBD

[edit] Coupling of simulations and model types

Problem
We probably have to incorporate different computation and simulation tools suited for different purposes (Stanet, INSEL, GIS). To which degree shall the SimStadt software support coupling of simulations of different type?

Constraints
Keep in mind, that INSEL does not realize (and is not restricted to) a specific solver. Therefore in some cases, it might be easier to reimplement some solvers/simulators within INSEL instead of providing an infrastructure of sorts for coupling.

Assumptions
TBD

Considered Alternatives
Three alternatives, with growing difficulty, are:

  1. Executing simulation models one after the other and chaining simulation results
  2. Using co-simulation in order to exchange partial results of simulations while they are running
  3. Providing some kind of infrastructure for 'real' distributed simulation of models of different type

Decision
TBD

[edit] How to implement workflows for performing simulation experiments?

Problem
In SimStadt we need to build different types of scenarios, must perform different forms of data preprocessing, will combine/evaluate different simulators and would like to analyze and visualize results comfortably. In consequence, simulation experiments can only be done by following quite complicated workflows.

The question is: How will the SimStadt workbench support workflows to perform (and replicate!) simulation experiments.

Constraints
Outcomes of simulation experiments will only be credible if the workflow and the simulations are understandable and reproducible.

Assumptions
TBD

Considered Alternatives
Workflow is

  1. executed manually
  2. hardcoded from the scratch
  3. hardcoded within a framework, e.g. by providing plugins for JAMES II
  4. encoded by scripts
  5. modeled explicitly, i.g. graphically (BPMN) or as XML-File (BPEL)

Manual execution, maybe following a written down recipe, can only be an exception since it is time consuming and error prone.

Decision
As pointed out in

  • Rybacki S, Himmelspach J & Uhrmacher AM (2012): Using workflows to control the experiment execution in M&S Software. In: George Riley and Francesco Quaglia and Jan Himmelspach (ed.): Proceedings of the 5th SimuTools conference, pp. 93-102, ICST.
  • Rybacki S, Himmelspach J, Haack F & Uhrmacher AM (2011): WorMS- A Framework to Support Workflows in M&S. In: S. Jain and R. R. Creasey and J. Himmelspach and K. P. White and M. Fu, (ed.): Proceedings of the 2011 Winter Simulation Conference, Institute of Electrical and Electronics Engineers, Inc., Piscataway, New Jersey.
  • and Rybacki S, Himmelspach J, Seib E & Uhrmacher AM (2010): Using workflows in M&S software. In: B. Johansson and S. Jain and J. Montoya-Torres and J. Hugan and E. Yücesan (ed.): Proceedings of the 2010 Winter Simulation Conference, pp. 535-545, Institute of Electrical and Electronics Engineers, Inc., Piscataway, New Jersey.

workflow support for controlling simulation experiments has many advantages on different levels.

TBD

[edit] RESTful web services vs. "big" web services

Problem
Since web services will be used to access and combine data sources and simulators, the question emerges, if "full blown" web services (WS-*) or RESTful web services shall be used.

WS-* is a set of specifications including web services description language (WDSL) for defining service interfaces and WS-BPEL for combining web services to (business) processes. There are also approaches to implement scientific workflows that way (see http://sse.cs.ucl.ac.uk/index.php?id=omii-bpel). On the other hand, RESTful web services use a uniform, simple, and stateless protocol (HTTP mostly) to access web services. They are more easy to use, but cannot define service interfaces syntactically (see http://de.wikipedia.org/wiki/RESTful).

Constraints
How steep is the learning curve? (At least one team member (Kai) has developed RESTful web services before.)

Is the software/middleware required all open source or must we use commercial products?

Where do Web Processing Services (WPS) fit into the picture?

Note that using WS-* often is a prerequisite for using existing tools for modeling and executing business processes (programming in the large).

Assumptions
TBD

Considered Alternatives

  1. Follow WS-* approach
  2. Employ RESTful web services

Decision
Pautasso et al. came to the conclusion: "REST is well suited for basic, ad hoc integration scenarios, WS-* is more flexible and addresses advanced quality of service requirements commonly occurring in enterprise computing." (see Cesare Pautasso, Olaf Zimmermann, and Frank Leymann. 2008. Restful web services vs. "big"' web services: making the right architectural decision. In Proceedings of the 17th international conference on World Wide Web (WWW '08). ACM, New York, NY, USA, 805-814. DOI=10.1145/1367497.1367606 http://doi.acm.org/10.1145/1367497.1367606)

Thus, for the sake of flexibility and easier usage, RESTful web services should be used within the SimsStadt workbench (alternative 2. above).

Decision proposed by Kai Brassel on the 12th of April 2013.

[edit] Consider pros and cons of using a classical client-server-architecture vs. web services

TBD Problem
Web services are server centric, that is the servers (GIS, simulators, databases) called from the client (workbench) do most of the work. However, a classical client-server-architecture may provide a more opportunities to balance workload between software components.

For a comparison see of both approaches see: http://stackoverflow.com/questions/10152115/web-service-vs-client-server-distributed-computing-technology

The overhead that comes with web services slows down the communication, say one request per 50 milli seconds vs. nano seconds for slot communication via shared memory, see: http://javafastsockets.com.

What exactly is the challenge? Why is it relevant for the architecture? What consequences does the decision have?

Constraints
Which constraints do you have to keep in mind? What factors influence the decision?

Assumptions
Which assumption have you made? How can you check those assumptions? Which risks are you facing?

Considered Alternatives
Which alternative options did you consider? How do you judge each one? Which alternatives are you excluding deliberately?

Decision
Who has decided? How has the decision been justified? When did you decide?

[edit] Consider pros and cons of using web sockets

TBD Problem
What exactly is the challenge? Why is it relevant for the architecture? What consequences does the decision have?

Constraints
Which constraints do you have to keep in mind? What factors influence the decision?

Assumptions
Which assumption have you made? How can you check those assumptions? Which risks are you facing?

Considered Alternatives
Which alternative options did you consider? How do you judge each one? Which alternatives are you excluding deliberately?

Decision
Who has decided? How has the decision been justified? When did you decide?

[edit] Template (copy before use)

Problem
What exactly is the challenge? Why is it relevant for the architecture? What consequences does the decision have?

Constraints
Which constraints do you have to keep in mind? What factors influence the decision?

Assumptions
Which assumption have you made? How can you check those assumptions? Which risks are you facing?

Considered Alternatives
Which alternative options did you consider? How do you judge each one? Which alternatives are you excluding deliberately?

Decision
Who has decided? How has the decision been justified? When did you decide?

How to

Contents

Document all important design decisions and their reasons!

Motivation

It is advantageous if all important design decisions can be found in one place. It is up to you to decide if a decision should be documented here or rather locally (e.g. in the white box descriptions of building blocks). In any case avoid redundancies.

Form

Informal list, if possible ordered by the decisions’ importance for the reader. Use the template below to structure your decisions.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox