Fluidlogic™ is a technology for defining, implementing, and deploying customized enterprise services. An enterprise service is client/server functionality that provides concurrency, security, interoperability, transactions, caching, and persistence in a scalable way. With Fluidlogic™, you have the power to customize enterprise services to suit your unique requirements.

From the three-tiered perspective, Fluidlogic™ is middleware – it sits in between the user interface tier and the database tier. Out of the box, Fluidlogic™ offers four deployment options: as a Stateless Session Bean (SLSB) EJB component, as a RMI server, as a Servlet, or as an in-process server running within the client application.

Fluidlogic™ is a cost-effective alternative to J2EE application servers. J2EE servers can be complicated, inflexible, and expensive. With Fluidlogic™ it is free to develop, test, and evaluate applications; you only purchase a deployment license for each physical machine on which you run a Fluidlogic™ application. A deployment license costs less than $500 US.

Fluidlogic™ competes against J2EE for applications running on a single machine. Here, Fluidlogic™ shines due to its low price, low complexity and ease of use, and the options it brings for future scalability. Fluidlogic™ complements and benefits from J2EE when it is deployed as a SLSB, and can be clustered via J2EE.

For organizations using EJBs, Fluidlogic™ is an alternative to Entity Beans, and can also clean up a lot of the typical stateless session facades employed to achieve transactional persistence of business objects. When Fluidlogic™ is deployed as a Stateless Session Bean other EJBs can be clients of Fluidlogic™ services.

Fluidlogic™ is developer-friendly: the APIs are straightforward and leverage web application development expertise. Services can be implemented to inject resources at the time they are needed. Fluidlogic™ applications are easy to test: no matter how your application will be deployed in production, developers can unit-test their code on their local systems without requiring any kind of container or local application server.

Fluidlogic™ is implemented in Java, and any Java application can be a client of Fluidlogic™ services. JDK 1.4 is required to deploy server-side functionality. Clients written in other languages are possible when they are capable of producing and consuming XML and communicating via HTTP.

If you are still in the decision making process about which technologies to use to develop your next enterprise application, here are the reasons we believe Fluidlogic™ should be part of your solution:

1) Maneuver Strategy: architectures based on Fluidlogic™ are open ended, maneuverable, and amendable to change. Any of the deployment configurations can be mixed or matched with the others, with identical functionality. You can migrate to a more scalable configuration without having to rewrite any code.

2) Degrees of Freedom: you can mix and match customized services that behave identically in all of the deployment configurations. You have virtually unlimited degrees of freedom in creating services.

3) J2EE server is optional = money in your pocket unless you absolutely positively need to spend it.

4) Reduced code + reduced complexity = lower entropy = lower resource requirements + happy programmers + more maintainability.

5) The specifics of your requirements match the specifics of your implementation – your work is directed at meeting your requirements, not ours. Fluidlogic™ does not mandate the arbitrary interfaces and supporting files required by other more heavyweight solutions.

6) All of the deployment configurations provide most of the same benefits as EJB-only solutions: robust authentication; centralization of code, configuration, and network services; distinct separation of code into tiers; distributed objects are optional.

7) Pre-built infrastructure to support JDBC persistence, clustered caching, robust authentication, optimistic locking, and state modification detection [dirty detection] help get your implementation going quickly.

8) Optional transparent client-side caching improves client application performance.

As you can see, Fluidlogic™ has both strategic and tactical implications. This is not an accident! Fluidlogic™ is designed to support strategies based on speed and maneuver. It is also designed to promote incremental change in a team setting – the day-to-day choices front-line programmers make will resonate with the architecture as a whole so long as some simple heuristics are applied consistently.

These propositions are addressed in the Introduction to Fluidlogic™ PDF, with more supporting information.

You may say: "Portability? Hah! I’ve heard that one before…"

In Fluidlogic™, portability means the ability to deploy the same application to an In-Process server, to a RMI server, as a Servlet, or as a SLSB and have identical functionality. In Fluidlogic™, such portability is possible by treating each of the deployment options as thin wrappers for an underlying server. This underlying server is in essence a Fluidlogic™ virtual machine. The underlying server is responsible for the execution of Commands, and since it is the same regardless of the wrapper around it, the functionality is the same.

We won’t lie: you can write non-portable code. Non-portable code would be code that is disallowed by one of the deployment options, such as code that attempts to manage Thread Groups or tries to set the Security Manager in an EJB. While this code could work in an In-Process or RMI Server deployment, it is disallowed by the EJB spec, and would be disallowed by the application server in a Fluidlogic™ SLSB deployment. If you want to maximize your deployment options, write code that does not do anything that is disallowed by the EJB spec.

Note: if you deploy to a J2EE environment and use J2EE style connection pools, your local testing configuration may differ slightly from the deployment configuration. The application code remains the same; the configuration can change independently.

Fluidlogic™ does not impose programming restrictions like J2EE does. Fluidlogic™ is about giving application architects, designers, and developers the freedom to address their unique problems in the way they best see fit. Therefore, if you forgo deploying on a J2EE server, you can do anything that is programmatically possible with Java.

Fluidlogic™ brings this question into sharp detail. If you need app server features such as Message Driven Beans, EIS connectors, JCA, XA, or clustered operation with transparent failover, then you need a J2EE application server. If you need concurrency, security, interoperability, transactions, caching, and persistence, and you want to leave your future options open, then all you really need is Fluidlogic™. If you need both sets of features, we recommend a Fluidlogic™ and J2EE combined solution.

Although Fluidlogic™ can be deployed via a Servlet, Fluidlogic™ does not replace the need for Servlets or JSP. Fluidlogic™ is middleware, and when deployed as a Servlet, it uses the HTTP protocol to communicate between the client application and the Server. Similarly, Fluidlogic™ uses the application server’s protocol when deployed as an EJB, and it uses RMI when deployed as an RMI server. No network protocol is used when it is deployed as an In-Process server.

If your application is a Servlet and JSP web application, you can still use Fluidlogic™; it is recommended that you use Fluidlogic™ as an In-Process server where the enterprise services run in the Servlet container’s process. You can also use the RMI and SLSB deployment options if you require physical separation and centralization of the middleware from the web tier.

The terms ‘application’ and ‘domain’ refer to the layers of functionality implemented on top of the Fluidlogic™ architecture. This includes any domain object model, front-end system, or other system that acts in the role of a client. A domain object model is a set of interfaces and classes that structures and interrelates the forces at hand in the context of your particular requirements, and a front-end system implements the user interface of your application. A client is any system that directly or indirectly issues commands to a Fluidlogic™ request processor.

The layers below Fluidlogic™ are termed the ‘data tier’ or ‘backend systems’, and are the source and/or repository of the information you wish to expose or otherwise manipulate via a client.