Last revised 8:00 ET Dec. 16, 2008
The Jazz Platform is geared to providing an integrated experience for customers engaged in software development. Here's how the Jazz Platform Technical Overview describes it:
Jazz is a team collaboration platform for the full software lifecycle, designed to support seamless integration of tasks across all phases of the software lifecycle (of which the above example scenario touches on a few common tasks in the middle of the lifecycle). Jazz is designed to be extensible both on the client and the server, and to scale from very small teams to large enterprise installations. It incorporates the notion of tool-supported process guidance, where the tools understand the development process the team has decided to use, and seamlessly help team members to follow this process without getting in their way. Jazz is not just intended to integrate existing point tools, but also to provide a platform upon which to build much more integrated lifecycle tool function than previously possible. When development tools are integrated across the lifecycle in this way, it becomes possible to do things unimaginable with a set of bolted-together point solutions. Integrated end-to-end tools like this can help teams build software more effectively, and make the software development activity more enjoyable.
The original design goals of the Jazz Platform (again, from the Jazz Platform Technical Overview):
Architecturally, the design center has been on a client-server architecture, with each client and server hosting a range of ALM components. Client-side APIs are in the form of a Java-based client library. The wire format for client-server communication is an internal implementation detail. The server hosts a range of ALM components, offering their services and storing their data.
There are a number of reasons why the particular architectural choices we made in the early days of Jazz allowed us to quickly get to the point of delivering Rational Team Concert 1.0. Looking at the road ahead, there are a number of reasons why some of the architectural constraints should now be loosened, allowing Jazz technology to serve as the basis for an even wider range of products.
The original vision and design goals of Jazz have not changed; however, the architecture of the Jazz is evolving to meet additional challenges.
There are two major architectural changes. The first has to do with how clients talk to servers. The second has to do with how servers are structured, and how servers talk to other servers. The two are not unrelated.
| Delta 1: Jazz servers expose their data resources and services through REST APIs. |
In Jazz Platform 0.6, the wire format connecting client and server is an internal, undocumented, implementation detail. Rather than continue in this vein, we are moving to exposing a Jazz server's data resources and services through RESTful resource-oriented web services using standard HTTP and documented, consumable formats. In this mold, the data resources and services are designed as REST APIs. By doing this we aim to achieve three things:
We see moving in this direction gradually, exposing more and more over time. The Jazz server's existing internal service interfaces will be replaced in time by REST APIs that have been designed for stability and wide interoperability. These REST APIs might sit atop the existing underlying data formats and service implementations, or atop completely new ones.
This move means that language-specific client libraries, while often still desirable, are no longer absolutely essential. The client- and language-neutral REST APIs provide the foundation for developing language-specific client libraries for whatever languages are popular. Since the REST APIs are documented, everyone has the information needed to write a client library for their favorite language.
| Delta 2: Jazz Team Servers become a logical entity for exposing the services of heterogeneous physical servers configured to work together. |
In Jazz Platform 0.6, a Jazz Team Server consists of a single J2EE-based server. Going forward, a Jazz Team Server will be a logical entity for exposing the services of heterogeneous physical servers configured to work together. By doing this we aim to escape the tyranny of the "all-in-one-box" server, and provide additional avenues for integrating new tools and products into Jazz. Data and services would no longer be required to inhabit the same J2EE server instance that hosts the other Jazz services and data. It would now be a feasible option to deploy a tool on a separate server - and not necessarily a J2EE-based one - and still have it appear to clients as well integrated with tools installed on other servers. This option would allow an existing server-based product to be integrated into Jazz without having to rewrite it.
A number of gaps are opened up when there are multiple servers, each storing its own data resources. In particular, all the servers need a way to tap into the same pool of users and projects, and mechanisms for process guidance. And clients need a query mechanism that will support searches across data resources stored on diverse physical servers. These needs are addressed by a set of core services for tying the parts together. Again, we see REST APIs as playing a key role in connecting services that may live on different servers, while keeping everything loosely coupled.
Having multiple servers also means that Jazz Team Server will now have to deal with the complexities of a distributed system on the server. Fortunately, this is well trodden ground, and there are existing solutions to draw on.
Taken together, these two changes give us an integration architecture that will put Jazz in the best possible place to evolve to meet the future. This, then, is how the original idea of the Jazz Platform is evolving into the Jazz Integration Architecture.
© Copyright IBM Corporation 2008. All rights reserved.