ZAP: The ZipTie Application Platform

---

Overview

The ZAP is a lightweight application server based on OSGi. The development of the ZAP was an outcome of the ZipTie open source project sponsored by AlterPoint, Inc.. The ZAP was in some ways created as a reaction to "traditional" J2EE application servers. The authors of ZAP have used J2EE in various commercial development projects and know all too well the failings of modern J2EE servers. They tend to be heavyweight and while they can be slimmed down it requires a lot of work. Most J2EE application servers are highly configurable, but this configuration leads to an explosion of complexity. The effort required to get all remote services (JNDI, JMS, EJB) running over SSL and running over a single port took a senior engineer nearly a week to accomplish on JBoss; not all of which effort could be blamed on light documentation, but also the myriad of configuration files containing references to factories and service names all of which had to be in perfect alignment to work.

The ZAP avoids these complexities by simply side-stepping configurability. Does this mean that the ZAP is any less powerful? No, it simply means that we made assumptions that apparently the architects of J2EE and the authors of JBoss weren't comfortable making. The ZAP assumes that you want all client/server communications to be secure. The ZAP assumes that you only want your server exposing one port to the world.

The ZAP also makes several other assumptions that reflect the underlying philosophy of it's authors.

• Remote APIs. Java is a great language with which to write servers. It's also a great language with which to write clients. However, we assume that in today's world developers of clients should be free to choose the language they see fit. Sure, your application may be Java on the server and the client, that's fine. But because the ZAP was originally designed to underly ZipTie, an open source application, the decision was made to enable clients written in any language, for example, PHP, .Net, Ruby, or Perl, the ZAP assumes that all remote APIs will be exposed as SOAP Web Services. We chose the best-of-breed implementation for modern Web Services, the Sun JAX-WS Reference Implementation (aka Metro). And, yes, we say that with some authority.
• Persistence. The ZAP assumes that any modern Java-based server application has a need for database persistence. We chose the best-of-breed implementation for this persistence, the JPA-based Hibernate 3.
• Componentization. The authors of the ZAP believe strongly in componentization. Some might even say extreme componentization. This is one of the reasons that OSGi was chosen as the underlying technology of the ZAP. There is the tendency in applications toward tight coupling as complexity increases, and while it can never be avoided entirely, without constant reinforcement of best practices a code-base will quickly devolve into a maintenance nightmare. OSGi alone does not solve this problem, but it's [nearly] rigid requirement on dependency declaration serves as a reminder as an application is built using it.

Getting Started