SOA kills ORM?

Recently I participated in several projects that heavily utilized services (message-based, shared-nothing, over-the-wire thingies). What I noticed is that object/relational mapping (ORM) tools are virtually useless for such projects. Indeed, significant, if not most value of ORM comes from ability to modify values in memory, using OO language constructs for that, and then just synchronize the memory with the database. This functionality goes completely unutilized in typical SOA application, where reads and writes are separated in time, use different objects and acces paths, and in fact can be performed from different machines. E.g., one service can read a list of tasks from the DB and return them as a message to the network peer. After traveling between peers this information (but not this specific object or message) in combination with information from other sources (e.g., user input) can be used to update a specific property of a specific task (written back to the DB). Has need for service/relational (or message/relational) mapping indeed arrived?

JoinJavaScript

Sometimes I have to use JavaScript for my daily programming, and while it takes some time to switch to it, it has certain beauty and allows some expressivity missing in "bigger" languages like Java or C#.

I tried to identify, what features make it shine, and what features might add even more to the mix.

So great and already present:

1. Free extension of any object with properties ("every object is a dictionary").
2. (Limited) introspection ("for in").
3. Closures as first-class values ("closure is a value", and even "closure is an object").
4. Prototypes for ad hoc extensibility, e.g., interception of closure invocation at prototype level.

Potentially great, but missing:

1. Ergonomic way to qualify property names (a la XML or RDF).
2. More and deeper interception - e.g., access to properties (get/put/foreach).
3. More advanced control operators - e.g., co-routines and generators.
4. Concurrency at language level.
5. More like a constraint on other features - capability-based security.

I see certain synergy among proposed features, so adding them may not automatically turn the language into a kitchen sink.

I would try to approach features 3 to 5 via join calculus. Now, if I only had time.

A Methodology and Tool for Top-down Relational Database Design

This paper presents a methodology for logical design of relational schemas and integrity constraints
using semantic binary schemas. This is a top-down methodology. In this methodology,
a conceptual description of an enterprise is designed using a semantic binary model.
Then, this description is converted into the relational database design.

THE HISTORICAL RELATIONAL DATA MODEL (HRDM) AND ALGEBRA BASED ON LIFESPANS

Critical to the design of an historical database model is the representation of the existence of objects across the temporal dimension — for example, the "birth," "death," or "rebirth" of an individual, or the establishment or dis-establishment of a relationship. The notion of the "lifespan" of a database object is proposed as a simple framework for epressing these concepts. An object's lifespan is simply those periods of time during which the database models the properties of that object. In this paper we propose the historical relational data model (HRDM) and algebra that is based upon lifespans and that views the values of all attributes as functions from time points to simple domains. The model that we obtain is a consistent extension of the relational data model, and provides a simple mechanism for providing both time-varying data and time-varying schemes.