"Things should be made as simple as possible, but not any simpler"
– Albert Einstein. Who can argue with that?

Fluidlogic™ facilitates the creation of secure transaction-processing systems with an emphasis on a portable architectural style and the minimization and/or elimination of duplicate coding of application-level objects.

J2EE systems that deal with persistent data typically duplicate code and interfaces in multiple files – CMP fields in XML, data transfer objects (DTOs) for transporting state from one tier to another, adapter classes to facilitate interoperation between the domain objects and the presentation tier, and DAOs that implement data-tier aware instances of presentation tier objects. Fluidlogic™ eliminates the anti-pattern of duplicating the domain object model in each tier in which it is used.

Fluidlogic™ provides authentication, transactions, caching, logging, and, depending on your configuration, secure connections (transport-layer security, or TLS).

All these services are pluggable – you can implement your own authenticator, transaction-oriented connection factory, cache implementation, and logging implementation. You can mix and match these components independently to suit your requirements and deployment topology.

Fluidlogic™ imposes no specific requirements for persistence. It allows you to roll your own, use JDO, object-relational-mapping (ORM), or even call on EJBs; you, as the service developer, are free to implement the functionality that suits your specific requirements. Fluidlogic™ is persistence-agnostic.

Fluidlogic™ automates the handling of database connections and other resources required to implement your services after you configure it to do so – you define a factory to provide your service-specific dependencies, and Fluidlogic™ injects these dependencies into your concrete commands when they are executed. Fluidlogic™ comes out of the box with factories for JDBC connections, you can extend this to suit your particular needs.

Fluidlogic™ facilitates client-architecture-neutral interoperability via HTTP and XML representations.

When deployed as a Servlet, Fluidlogic™ can be configured to maximize compatibility with HTTP 1.1, and you can plug in handlers to control how objects are marshalled/unmarshalled to/from HTTP. Therefore, interoperability with non-Java architectures can be achieved, without sacrificing concurrency, security, transactions, caching, and persistence.

Fluidlogic™ facilitates compositional transactions. Multiple commands can participate in the same transaction. Thus, services are fine grained and clients determine what objects participate in any given transaction.

All commands in a Request succeed or fail as a unit. Multiple Put, Post, and Delete commands are allowed per transactional Request. A Get command cannot be in the same Request as a Put, Post, or Delete command – each Get command is executed independently in it’s own Request. Multiple Gets in a single Request are not allowed.

Fluidlogic™ eliminates the ‘distributed’ aspect of n-tier systems for applications whose requirements do not require a physical separation of the middle tier from the front-end tier.

Fluidlogic™ provides the same interface to services for in-process or remote clients. In the case of in-process clients, Fluidlogic™ services run within the client application. For remote clients, Fluidlogic™ services run in a different process, possibly on a different machine from the client. In-process clients benefit from reduced overhead and latency and are therefore the most efficient deployment topology.

Fluidlogic™ facilitates the encapsulation of application functionality into as few classes as possible with the caveat that the architecture requires separation of business interface (abstract commands) from their service-dependent implementation (concrete commands).

Command-based architectures can suffer from “command explosion”, where each command has a separate object. Fluidlogic™ does not suffer from this problem since it aggregates commands that are naturally correlated – commands that operate on the same data or object – into a single file.

Fluidlogic™ is designed to be as protocol-compatible with HTTP 1.1 as possible. Thus, Fluidlogic™’s request-response application protocol can use HTTP natively if required, and in so doing applications can benefit from existing HTTP infrastructure, security mechanisms, HTTP proxies and caches, etc.

Native HTTP 1.1 compatibility is what allows Fluidlogic™ services to be exposed to clients written in languages other than Java.

Fluidlogic™ is designed to be fully configuration-compatible with EJB. Therefore, if application-specific services follow the same rules as required when implementing Stateless Session EJBs, then EJB application servers can be used to provide clustering for Fluidlogic™ enterprise services.

A J2EE application server is optional, not a requirement. If your requirements dictate that failover, clustering, and high-availability as provided by J2EE is needed, Fluidlogic™ services will acquire these benefits when deployed on a J2EE app server that provides them.