J2EE vs CompStrm

Having spent a week in J2EE class, it is easy to be seduced by the architecture. It is well structured, and highly scallable. And very rich, addressing a range of transactional needs, while also providing reasonable security measures. Its scope is comercial enterprises, and it is a good fit.

The heart of J2EE is a directory server (LDAP), running both JNDI and the Identity server. The JNDI server is used to locate and configure EJBeans, while the Identy server handles users, preferences and role assignments. It is very much a centralized architecture.

CompStrm is driving towards an inverted architecture, where each user has control of his/her own system, but can share structures or streaming structures with other users.

An eariler version of CompStrm already did this. But without the added dimension of time, and only for passive structures (like Wiki pages). This time around, I am adding (application) logic to the sharable structures.

But sharing should be done safely. And there are better security models for sharing data and logic separately, with the logic deciding which data becomes which type of object rather than having that information coded in the data.

One thing J2EE does not give much attention to is movement of data/logic across trust domains. Rather, you have one large trust domain and centralized control over deployment.

In contrast, a CompStrm network would be a number of small trust domains, which provide much more flexibility and should be easier to secure, providing the architecture properly addresses those cross-trust domain issues.