Hello Everyone
Thanks, Eric, for the heads-up regarding Time Conscious Objects (see "OOPSLA
2003 observations"). I've jumped through hoops at the ACM website and
finally, after shelling out the fee, hope to get the article tonight!
I thought the list might be interested in another initiative in this area.
I believe that the time-dimension of temporal objects (or, to be precise,
BOTH time dimensions) are orthogonal to the domain itself. The explicit
modelling of time variance makes for non-intuitive reference navigation and
horrendous query filters!
Ogilvie Partners has commenced an initiative to provide support for
transparent time variance through JDO (sorry - JDO again!). This approach
will remove infrastructure coding relevant to time variance from the domain
model. To read about our initial ideas please visit
www.OgilviePartners.com. Click on the link "Time Variance for JDO". There
are five short pages on the topic. Perhaps the most interesting one to this
group will be the "Worked Example" page.
Comments are welcome.
RobinRoos
Other time and history related ideas....
Several entries at PLoP 98...
http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/
And the incomparable Ralph Kimball. The articles are about star schema
database design, but they are worth understanding even for a 100% OOP
system...
http://www.ralphkimball.com/html/articles.html
PatrickLogan
Hi Everyone,
Nice to see some interest in the topic of "Time", because it is so often
trivialised and implemented ad-hoc in multiple ways within a single system.
Have checked out Robin's link and have also seen the references that Patrick
mentioned. Here are just a few comments on "Time" from my perspective:
- Robin's initiatve seems to tie in "Time" with JDO-based persistence. Yes,
persistence of time-dependent information is an important aspect in many
cases, but is it only one part of the the larger picture. In fact I don't
perceive it to be at the core of "Time". Some time-conscious objects
(depending on the type of application you're working on) may be very
"dynamic" and quite short-lived, yet still require time-conscious behaviour
during their existence.
- The "Time Variance for JDO" material correctly points out that there is a
need for [at least] two "dimensions" of time. However I think the approach
to the two dimensions is not well thought-out, especially having four
Date/Timestamp attributes in one class is not very elegant. The concept of
"Interval" seems to be lacking.
- Without going into the nitty-gritty details here, the second dimension is
better modelled by what we call "Baselines" in TCO. Each baseline has a
"baselineCreationTime" (when the baseline was created), "baselineBranchTime"
(at what point the new baseline branches of the previous baseline.
- TCO attempts to provide "time-conscious objects" with useful Time-related
behaviour. "Intervals" are a natural way to think about a timeline, and in
TCO we strive to enable the user to think in terms of objects and intervals
during which these objects may have certain states - "Interval" being the
primary concept, and "State" being a secondary [implementation] concept.
- In my experience Time-related behaviour often has to do with comparing the
timelines of "similar" objects (or of object states within a timeline).
Example query: At which points in time did a group of attributes of object A
have the same values as the same group of attributes in object B? We're
currently still working on that part of the TCO API, i.e. validating our
thinking against practical scenarios.
Other things that we've got in our pipeline:
- Modelling of repeating "calendars". I.e. certain attributes may change in
a cyclical manner, and there may be cycles of different lengths for various
attributes. Think of the [default] content on displays in airports and train
stations, or of cycles in electricity consumption (daily, weekly, yearly)
when you're modelling electricity demand and supply, etc.
- Dealing with "fat" time-conscious objects in distributed environments. You
may not always want to carry around the entire "lifeline" and all
"baselines" of an object, yet want to be able to access it in a lazy-load
fashion.
- Seemless structural evolution of time conscious objects. I.e. once you've
got time conscious objects in production, you may get to the point where
requirements change and hence the object structure needs to evolve. Data
conversion scripts for the database would be the traditional approach. But
perhaps there's a more intelligent approach? Especially if you've got 24*7
requirements...
- Integrity of objects. It can get very costly to always check integrity.
For example if an object contains a <<time-conscious>> object, and the
<<time-conscious>> object logically ceases to exist at a certain point, then
you still have the reference to it, but you may violate a cardinality
constraint "> 0" from the point where the contained object logically ceases
to exist. When should such integrity checks be performed? Perhaps in some
systems it makes sense to run them based on a regular schedule. Think that's
a hard topic. Don't pretend to have all the answers.
We're planning to make TCO available in open source format before end of the
year, and we're looking forward to constructive feedback and further ideas!
JornBettin
Hi Jorn
> Nice to see some interest in the topic of "Time", because it is so often
> trivialised and implemented ad-hoc in multiple ways within a single
system.
Agreed! I downloaded the ACM document cited here by Eric Evans, but found
it to be relatively superficial. I had been meaning to contact its authors
separately but, since you're evidently on the list, I can ask you here if
you have further information on TCO!
Jorn, thanks for considering the ideas I've published on
www.OgilviePartners.com regarding transparent time variance for JDO. I
appreciate your comments, specifically regarding intervals/baselines and the
complexity of referential integrity for temporal objects and relationships.
I'd like to clarify a few points here, not specifically in answer to your
comments.
Firstly, the ideas behind my initiative are to abstract the complexity of
modelling, accessing (by Java reference traversal) and querying temporal
object collaborations. JDO has a convenient architecture through which to
provide this abstraction and, with input from sufficient perspectives
(including yours), I believe we can do a good job.
Secondly, by exploiting a persistence architecture to underlie an
abstraction of time variance I immediately face two restrictions. (1) The
time variance only applies to data which is persisted in the datastore: this
mechanism cannot apply time-variance to transient objects which never have
persistent state. And this abstraction further means that (2) object graphs
will behave differently if they are transient than they do if they are
persistent. JDO prides itself on the fact that transient and persistent
instances of the same class are functionally equivalent, and therefore JUnit
can be exploited to test domain objects of JDO-based applications without
even connecting to a datastore if so desired. This can help to focus
regression testing on individual functional aspects, independent of
infrastructure concerns, although of course the infrastructure must then be
well covered by other tests. With transparent time variance as I have
proposed it a transient object graph represents an instant in time, whilst a
persistent object graph can include time variance. The programming model
for transient vs. persistent objects is unchanged, but versioning is only
available in the persistent case.
As long as potential users of the capability are aware of these restrictions
I believe the JDO-based concept will have wide application. But I do not
expect to solve all possible uses of time. To do that would probably need a
time-variance "container" in which temporal objects exist, with
time-variance being considered orthogonal to persistence. The container
would provide versioning services, and would expose methods by which these
services can be invoked by clients. All object-to-object navigation over
temporal associations would be indirected through this container so that the
appropriate version of the target instance can be resolved. (This is
directly analogous to the way in which, in JDO, such navigation is delegated
to the StateManager so that the target instance can be lazily loaded from
the datastore if necessary.) The difficulty with a temporal container comes
in terms of queries that span temporal relationships. A temporal container
which tried to solve this complexity would need to offer a query language or
intercept queries expressed in some existing query language, and inject the
appropriate temporal constraints before the query was actually executed.
This is where JDO excels - the implementation already intercepts the query,
and so the capability can easily be added.
My current proposal could theoretically be extended to cover time variance
for transient-transactional instances. The instances would need to be
transactional so that there is a definite point at which potentially
multiple changes are collected to form a single new version. This could be
achieved in JDO since transient-transactional instances are governed by a
StateManager. However it is not currently my intention to address time
variance for transient-transactional instances. As the working group is
assembled I will be asking for the group's input on the overall scope,
including issues such as this, as we start the project.
Kind regards,
RobinRoos
> Modeling of repeating "calendars"...
I'm not sure how well known this paper is, but it's worth reading...
http://www.martinfowler.com/apsupp/recurring.pdf (PDF)
"Many business processes are based on recurring events, of the form "pay
salaried staff on the last Friday of the month". In this article I
describe how we can model recurring events in such a way to allow quite
complicated recurring events to be expressed."
PatrickLogan
Here is a specialized paper where time has an important element. I
haven't waded through it myself, but someone might find it
interesting. The title is An Object-Oriented Approach for Modeling
Urban Land Use Changes.
http://www.urisa.org/Journal/protect/Vol14No1/raza%20pages.pdf
RobertBenson
TimeConsciousObjects is mentioned on: ThreadView
