That's OK, curiosity is always a positive thing in my book. I'm going to
include the proposal text in my thesis anyway. So the feedback is much
appreciated. Be warned though, I have a lot to say about this subject, and
it is going to be somewhat technical :-)
2011/4/16 Michael Bedward <[email protected]>
> Hi Kenneth,
>
> Thanks for that - the new text helps somewhat, although as a naive
> (EMF-wise) reader I'm still unclear on the advantages for critical
> applications. In a past life I've worked on wildfire modelling,
> including reviewing software used for real-time fire incident
> management, so I've been trying to relate your description to that
> context. The way I read your text, EMF is favoured because it can
> increase system reliability and decrease development iteration time.
What I'm missing is what you can do with that approach that you can't
> do otherwise, or perhaps can't do nearly as well.
I do not claim that EMF is the only solution, or even the best solution :-)
And you are right, it is the increased system reliability and faster
iteration cycles, compared to other frameworks, which is the primary
motivation. For more information, read the longer answer below :-)
> In particular, the
> connection with temporal data remains unclear.
>
> If you could point me to any examples or references that speak to this
> I'd be very interested, but don't waste any time labouring further
> over the proposal because I'm just asking out of curiosity.
>
OK, I'll try to explain it in another way. Systems that change over time
have a temporal component. Discrete Event (Dynamic)
Systems<http://en.wikipedia.org/wiki/Discrete_event_dynamic_system>
(DES
or DEDS) is part of this problem domain. The term "discrete" only implies
that system changes are driven by discrete events, or more precisely, each
time a event start or ends (which is the discrete part of the event) the
system may change. No assumptions are made about time or system states,
which can be discrete or continuous or both.
When modeling such systems, historical time is important. Some sort of temporal
database <http://en.wikipedia.org/wiki/Temporal_database> which stores the
time information associated with each event is required. *This is where EMF
enters into the equation*. Since EMF have a notion of
events<http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/common/notify/Notification.html>,
this capability can be easily be used to store the history of change. The
EMFT project
Temporality<http://www.eclipse.org/modeling/emft/?project=temporality#temporality>
(wiki <http://wiki.eclipse.org/Temporality>) implements this in a
non-intrusive manner following a approach similar to my
proposal<http://docs.codehaus.org/display/GEOTOOLS/EFeatureDataStore>.
Here is an example of what temporal EMF can do.
Imagine a chain of search assignments, each having a one of the following
states: *draft, ready, allocated, assigned, executing, completed, aborted*.
Now imagine the objects *Assignment *and *AssignmentQueue* being modeled
using temporal EMF. It is now possible to store the *change history* for
attributes like *Assignment.getStatus()* and *AssignmentQueue.getSize() *which
is persisted along with the EMF model itself.
As a systems and control theory engineer, this is clearly a very powerful
property of EMF. It enables all sorts of interesting things like prediction
and model-driven decision support. EMF Temporality is quite old though (+3
years since last commit), and it does not appear to be actively managed. The
code
however<http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.emf/org.eclipse.emf.temporality/?root=Modeling_Project>is
quite modest and easy to review, so I don't expect to much trouble
ahead
on that one.
>
> Michael
>
>
> On 16 April 2011 07:25, Kenneth Gulbrandsoy
> <[email protected]> wrote:
> > Hi!
> > The feedback is much appreciated. See my response below.
> >
> > 2011/4/14 Michael Bedward <[email protected]>
> >>
> >> Hi Kenneth,
> >>
> >> I'm one of the PMC members. Welcome, and thanks for putting up your
> >> proposal.
> >>
> >> I also work with data from experimental settings, and having spatial
> >> and temporal components, so I'm interested in your proposal. However,
> >> after reading it I don't properly understand what, precisely, a
> >> spatially-enabled EMF provides. This could be just because I'm not an
> >> EMF user and have only a basic understanding of its design and use,
> >> but your proposal would be easier to digest if the last section was
> >> moved to the beginning (rather than the proposal leaping directly into
> >> implementation details) and described more clearly what your module
> >> will provide that is not available currently, ie. what GeoTools users
> >> could do with it that they cannot do, or do easily, now.
> >
> > I agree. My first draft had the background section at the beginning. It
> is
> > now moved to the front again, and totally rewritten. A use-case section
> is
> > also added (still a work-in-progress) so the benefits of spatially
> enabled
> > EMF models is easier to understand for those who do not know EMF or
> > model-driven engineering intimately.
> > Check it out:
> http://docs.codehaus.org/display/GEOTOOLS/EFeatureDataStore
> >
> >>
> >> Michael
> >>
> >>
> >> On 14 April 2011 10:18, Kenneth Gulbrandsoy
> >> <[email protected]> wrote:
> >> > Hi list!
> >> > I have completed my proposal for adding spatial support to EMF models.
> >> > The
> >> > proposal can be found
> >> > here http://docs.codehaus.org/display/GEOTOOLS/EFeatureDataStore.
> >> > I believe the next step is to ask for access to the unsupported folder
> >> > in
> >> > the SVN repo so code can be shared and reviewed by those who are
> >> > interested.
> >> > Sincerely,
> >> > Kenneth Gulbrandsøy
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Benefiting from Server Virtualization: Beyond Initial Workload
> >> > Consolidation -- Increasing the use of server virtualization is a top
> >> > priority.Virtualization can reduce costs, simplify management, and
> >> > improve
> >> > application availability and disaster protection. Learn more about
> >> > boosting
> >> > the value of server virtualization.
> http://p.sf.net/sfu/vmware-sfdev2dev
> >> > _______________________________________________
> >> > Geotools-devel mailing list
> >> > [email protected]
> >> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >> >
> >> >
> >
> >
> > Kenneth
>
Since you already is familiar with a domain closely related with the one I'm
currently working on, you may find it interesting to review the proposal in
context my problem domain.
To start of, the title of the thesis I'm working on is "Model-driven
Decision Support for Search and Rescue". Because the search and rescue
domain is both time-critical, asynchronous and ad-hoc in nature (network
access is not guaranteed in the field), the distributed decision support
system (DDSS) topology must support concurrent editing of a shared
(distributed) model. At any given point in time should only exist one model
instance for each managed incident. EMF supports this by combining several
EMF plugins (EMF Compare + CDO with some additions to ensure data
integrity). Of course, other frameworks for spatial and temporal data-driven
systems do the same, but the network topology which many of these solutions
require, does not work well with the requirements in the search and rescue
domain. There exist frameworks for DDSS implemented in Java which are more
domain specific then EMF, Dicodess <http://dicodess/> is one such example.
The support for spatial data is limited though, and the UI patterns are
seldom well suited for the application domain of DDSS for search and rescue.
Most systems based on server-side RDBMS can not be used because of the
network topology it requires. Another problem with server-side RDBMS is the
node distribution problems these type of RDBMS introduce. Installing MySQL
or a PostGIS on every node in the system is overkill. Only RDBMS that can
run as embedded databases, are really feasible to deploy using Java webstart
or similiar technologies. However, none of the RDBMS in the public domain
that I know of, have frameworks with modeling tools and capabilities
comparable to EMF (please correct me if I'm wrong).
The topology which I believe is the most robust and appropriate in the
search and rescue domain is peer-to-peer. In a peer-to-peer topology, each
DDSS node is able to work on it's own, without the need for server access.
Each time nodes communicate, states are synchronized and conflicts resolved.
This makes the DDS very robust because every node have sufficient
information to work on it's on. If the network connection is lost, the user
is still able to work without to much trouble. Furthermore, the peer-to-peer
topology is very similar to the ad-hoc nature of the actual organisation
structures of search and rescue operations worldwide.
Think of the following situation:
1. A emergency call is received by the incident commander
(IC<http://en.wikipedia.org/wiki/Incident_Commander>).
The IC receives/inputs the distress message into a system node, looks at the
map and makes a short list of things which the standard plan does not cover.
If the IC is stationed, all this is done at the office. If the IC is a
volunteer, or home-based (which is the case many places around the world),
this task is done in-situ where the IC is located. In both cases, the only
active node currently managing the incident is the IC node. At this point in
time (typically 0 - 10 minutes after the call), the IC node does not have to
serve others, *it is standalone*.
2. The IC then activates the personnel, and moves to the staging area. At
location, the IC establishes an incident command post (ICP) and assembles
the ICP team as personnel arrives. Each member of the ICP team runs
a DDSS node peered with all other nodes in the IC system
(ICS<http://en.wikipedia.org/wiki/Incident_command_system>).
Because access to the outside world is not guaranteed, the DDSS nodes
communicate on a local network established at the CP. In this setting, *
master/slave* mode is entered. This allows for load-balancing, task
re-allocation, and node self-organization. Which one that actual become the
master, is decided using a handshake algorithm. Since every DDSS node
have the ability to be a master another node takes over automatically if the
current master has failed. The handshake algorithm degrade gracefully down
to standalone mode (no other nodes answered).
3. If a network is available between ICPs, several ICPs can stay peered
to form an aggregated ICS. Same degree of decoupling applies here, none of
the individual ICS are dependent on each other. This is a critical property
which all DDSS for time-critial operations like search and rescue must
support. This is called *master/master* mode which maps nicely to the
behavior of two IC cooperating to resolve a common problem by dividing the
task into separate areas (also known as area commanders).
If a common network access is available, a name-service (portal) could be
used to register each running DDSS node. This makes it easier for standalone
nodes to discover masters (master/slave handshake) and masters to discover
masters (master/master handshakes).
As time passes, ICP teams changes, hence nodes change and node numbers grow
and decay in sync with the operation life cycle. Scalability is therefore
another important property that the DDSS must support, something that a
hybrid peer-to-peer topology as described above solves reasonably well.
That's all for now. Stay tuned :-)
Kenneth
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
