Appistry EAF 3.8 goes live

We showcased Appistry EAF 3.8 during JavaOne a couple of weeks back. At the time, v3.8 was available on Peer2Peer as a beta download, as that version was making its way through QA. Those same bits, Appistry EAF 3.8.0.14 to be precise, are now blessed and available as a production download!

So what’s new with Appistry EAF 3.8?

New Features

• Fabric Upgrades
• Okay, so this isn’t really a new feature, but I’d like to briefly discuss upgrading your fabric. We have many, new members that have joined us on the Appistry Peer2Peer developer portal. Those of you that are new to the fabric may be saying at this point: "Oh no, a new fabric version! Now I have to upgrade all the boxes in my fabric!" This thought is one of the things that turns many people off to distributed computing: maintaining the software on your cluster of servers. However, Appistry EAF makes this process quite simple. A fabric is administered as an single entity, and not as individual servers. The fabric self-organizes and makes sure that all workers running on the fabric are using the same versions of all  fabric software, configuration files, far files (more on these below!), fabric applications, and associated files. The fabric does this for you automatically. As many of you are new to the fabric, and likely have installed Appistry EAF v3.7, I’d like to invite you to read about the various paths to Fabric Upgrades, and then, if you have an older version of the fabric, feel free to go ahead and upgrade to Appistry EAF 3.8. One last note: one of the upgrade options discussed in Fabric Upgrades is deploying a fabric.upgrade file. With v3.8, we will soon be providing, for the first time, the deployable fabric.upgrade files on the Peer2Peer download site. 
• Fabric-enabled Java Spring Beans
• With v3.8, we have extended our support for fabric-enabling Java Spring beans. Appistry adds Fabric support to Spring’s ability to call remote Spring beans via various protocols (RMI, Hessian, JAX-RPC, etc.).  Appistry provides a FabricProxyFactoryBean that is wired to the interface of the Spring bean to be  fabric-enabled. Local bean A that used to call local bean B can now be wired to call a remote, fabric-deployed instance of bean B with no code changes. What about bean B that is deployed on the fabric? It couldn’t be simpler. The bean is wired like any other Spring bean, and is packaged and deployed as part of a fabric application (providing version control and encapsulation). The fabric loads bean B and exports it as a service available on the fabric, again, with no changes to the existing code. Fabric-enabled Spring beans automatically inherit the scalability and reliability of the fabric, as well as the ability to be configured (again, with no code changes!) to act as unlimited, limited, and exclusive fabric services. You can read about our Spring support here and here.
• Plain Old Java Objects (POJOs) without Spring
• Perhaps you don’t want to use Spring? With v3.8, we have extended our support for Plain Old Java Objects (POJOs) by defining a new class of fabric executable actions called Java Components. Prior to v3.8, Java developers were required to deploy their Java code on the fabric as Tasks. Java tasks required the use of annotations to integrate the developer’s code into the fabric. Though this was lightweight, we were aware that many customers wanted to deploy code on the fabric in a "touch-less" manner. Indeed, one customer has what they call "million-dollar-beans", Java beans that if altered, even to just add annotations, would require a one million dollar QA cycle before redeployment. And so we have Fabric Java Components, an alternative to Fabric Java Tasks. Java Components are POJOs deployed on the fabric with no requirements for code changes, including annotations. Also, unlike the more method-oriented Java tasks, components are defined at the fabric application metadata level as objects, aligning better with the way Java developers think of their services.  You can read here about Fabric Components for Java.
• What about Plain Old .NET Objects (PONOs)? We’ve not forgotten our .NET users. Fabric Components for .NET are on their way. We’ll keep you posted.
• Far files or "How do I share libraries and common support files across multiple fabric applications?"
• Prior to v3.8, if a user deployed two or more fabric applications that used the same shared libraries (for example, DLLs, Linux .so libraries, or JAR files), they actually had to deploy copies of those libraries in each fabric application. Obviously this was not optimal from both space usage and management perspectives. With far files (FAR means Fabric Archive), the user can now package together libraries to be shared by multiple fabric applications. Each far file has a version and a unique name, and is deployed on the fabric as a stand-alone package that is not associated with any fabric application. In turn, fabric applications can now specify in their metadata that they use one or more particular far files. When a fabric application that uses a far files is loaded by the fabric, the contents of the far file are added to that application’s appropriate execution paths (classpath for Java JAR files, PATH (and LD_LIBRARY_PATH) for DLL/SO files). Multiple versions of far files can be deployed on the fabric, and in turn, different fabric applications can use different versions of the shared libraries. You can read about our FAR file support here.
• Affinity or "How do I get there from here?"
• With Appistry EAF 3.8, we have introduced Affinity features into the fabric execution path. Fabric Affinity gives the application developer control over which worker runs their component and/or task code for a given fabric request. For example, perhaps the developer wants their code to execute on a given worker that has some resource (a particular file or cache, special hardware, a certain amount of available memory, etc.). The developer specifies the particulars of resource availability (as well as the particular affinity strategy for choosing the correct worker) in an affinity task or component that is deployed as part of their fabric application. In turn, these fabric tasks or components are associated with a fabric process flow. Upon execution, the process flow uses the affinity tasks or components, and the declared affinity strategy, to direct execution of the user’s main code to the correct or best-fit fabric worker. Affinity strategies include B0olean strategy (simple yes/no: is this the right worker for the job?), Resource-based (does the worker have a given resource?), Rank-based (is this worker the best-fit for the job?), and Ranked Resource (is this worker the best-fit for the job and has the resource needed?). You can read more about Affinity here.
• Easier configuration of fabric-based Java Virtual Machines
• In prior versions of the fabric, control over Java Virtual Machine (JVM) settings was limited and, quite frankly, difficult to configure. Additionally, setting the correct JVM information on the system PATH (and LD_LIBRARY_PATH) required manual setup. With v3.8, we overhauled all of this functionality. First, there is no need for manual PATH configuration at installation time, as the Appistry EAF services now discover the Java installation and configure the runtime environment appropriately. Second, with Appistry EAF 3.8, you can easily and flexibly configure your JVM settings (e.g. JVM memory settings, classpath settings, and other JVM arguments). These settings can be defined for all JVM instances fabric-wide, as well as overridden for individual fabric applications. You can read about Java Virtual Machine configuration in the fabric here.
• Built-in Appistry EAF Community Edition License
• Our new open distribution model for Appistry EAF Community Edition has been very successful. A quick update perhaps for those that don’t know what I’m talking about. Appistry EAF Community Edition is our Appistry EAF product bundled with a Community Edition license. Anyone that downloads the Appistry EAF Community Edition from the Appistry Peer2Peer developer portal receives a Community Edition license that is good for five servers and/or ten CPU cores. This license is perpetual (doesn’t timeout or die), and can be used for production applications if you wish (the details of the license can be read by going to the downloads link). Support for Appistry EAF Community Edition is provided through the Peer2Peer forums. In the current Appistry EAF 3.7, the Community Edition license is emailed to you separate from the download. With Appistry EAF 3.8, the Community Edition license is built into the product, therefore allowing the Community Edition user to skip the step of deploying a license file. Of course, if you decide you need a larger fabric, or want higher-level support, and purchase a commercial Appistry EAF license, we will provide you with a new license that you can deploy to your fabric.
• Operating System Support
• With Appistry EAF 3.8, our fabric-supported operating systems are:
• Red Hat Enterprise Linux 4
• Red Hat Enterprise Linux 5
• SUSE Enterprise Linux 10
• Microsoft Windows XP (SP2 and SP3)
• Microsoft Windows Vista 32-bit
• Microsoft Windows 2003

More information about Appistry EAF 3.8 can be found in the Release notes.

I hope you all enjoy working with v3.8. If you have any questions, or want to share with us the cool things you are doing with the fabric, drop by the Peer2Peer forums.

We’ll see you there!

Guerry