Adobe LiveCycle 8 gets SOA right

A lot of vendors are claiming to be “SOA compliant”; whatever that means. Unless you have made such a claim within the context of an established metric, such as the OASIS Reference M odel for SOA or IBM’s Big Red Book of SOA Patterns, such claims are largely hollow. At a recent Syscon event in New York, my colleagues and I howled in laughter as we overheard someone talking about how with their company’s offerings, within 3 years many people might be able to do SOA, AJAX and ESB together. So before I make ay claims, I want to quantify a few things about SOA.

The OASIS Reference Model for SOA, a well scrutinized committee specification, provides the context for the rest of this blog entry. The RM alone is not sufficient to make the claim I have in the title, so I will augment it a bit. For SOA to be done right, a ubiquitous set of protocols must exist to facilitate the widest possible range of service bindings as possible with the minimal set of complexity. Once a large group of services exist using a common set of protocols and/or standards, a virtual bus exists where services may be consumed by consumers supporting the set of protocols and standards. This is what is often called a “service bus”. Additionally, a common processing model and a common set of invocation patterns aid the virtual bus in providing consumers an easy onramp to use the services on the bus.

Adobe LiveCycle has matured a lot in version 7.0+ and lots of SOA-ish behavior is present in the current version, but some real breakthroughs are coming in LiveCycle 8 as it gets a specification for service developers to use to create such a bus. This is partly due to SOA in general maturing and Adobe’s vigilance in keeping atop the standards around SOA and Web Services.

For starters, simple tasks like standard naming conventions for services across the entire platform are part of the core design specifications. This makes is far easier for developers to intuitively find services via the service registry. The service registry itself is a major step forward from LiveCycle 7. Event though LC7 employed a service registry, it was likely under-optimized for use within the platform and largely tasked with form management functions in LC 7. In LC 8, the core service registry is a central resource that can be used by the entire platform for registering and referencing services.

In LC8, Services are layered more consistently. Rather than each component simply determining its’ own level of abstraction for an API, the unified service designs classify services into different layers. The lowest layer is the native API’s for a component (such as a Java Interface) and connectors bridge the gaps to map the endpoints from various wire protocols to the underlying interfaces. Managed transparency is present and the interfaces are also agnostic to the wire protocols used by consumers to deliver their requests to the service container.

LiveCycle 8 will be previewed at the MAX Conference this year in Las Vegas by Matt Butler. I look forward to attending the talk and finding out more. It should be a pivotal moment in the life cycle of Adobe LiveCycle as the SOA story continues to mature.