History of Java CAPS product lines

Skip to end of metadata
Go to start of metadata

This diagram describes the history of Java CAPS product lines coming from the SeeBeyond acquisition.

I have started the diagram with e*Gate 4.0 around 1999. Before this major release we had a product called DataGate which release number is 3.6.

The two light blue boxed define the two major lines:

  • e*Gate 4.x which has the following architecture: Registry, Control Brokers, e*Ways
    In this line, the unit iof development is called a "schema".
  • ICAN and Java CAPS 5.x which has the following architecture: Repository and Integration Servers
    In this line, the unit iof development is called a "project"

By and large, a platform can be upgraded without major code modification within one the two boxes but not from the 4.x box to 5.x box. However the SRE messaging server is interoperable with the ICAN and Java CAPS messaging servers. That means one can bridge an SRE platform with an ICAN or Java CAPS one and exchange messages back and forth.

Java CAPS 6 inherits the Repository from the 5.x line. You can import any project from 5.0.5 onwards into the Java CAPS 6 Repository.

Java CAPS 6 also includes the Open ESB JBI engine in the same runtime which the SUN Application 9. You can bridge a Repository-based project with a JBI-based project directly because the runtime is common.

Significant events:

1989: SeeBeyond was incorporated under the name of STC: Software Technology Corp.

1999: release of e*Gate 4.0. This product introduces a new distributed architecture. The components message queues, message translators and application adapters are defined in a central repository. The components are instanciated at runtime in different processes and potentially different servers, all comunicating together. This distributed architecture can be easily scaled by replicating components to handle large throughput. The language used for message translation is a variant of LISP called Monk.

2000: SeeBeyond enters the stock market. The last release of the e*Gate 4.1.x line is out: 4.1.2. Already has some support for Java in addition to Monk.

2001: release of e*Gate 4.5.0. This release enhanced the support of Java so that it is the main language for programming the platform. A graphical environement for developing message handling (tranformation and routing) code is available. The message queuing engine is compatible with the standard JMS (Java Message Service).

2002: the last release of the 4.5.x line is out: 4.5.3

2003: release of Integrated Composite Application Network (ICAN) Suite v5.0 This suite introduces a new architecture based on J2EE. The development environement is based on Netbeans and is fully integrated amongst the various modules of the suite.

The Schema Runtime Environement (SRE) is a continuation of the 4.5.x product line. It includes a JMS Message server fully interoperable with ICAN J2EE. The "SRE" line continues to be supported with updates and fixes and provides a migration path for all projects since 4.0 using either Monk or Java. As of today we're at SRE 5.0.5 Update 1.

2004: The last release in the 5.0.x line is 5.0.5. This release continues to be supported and update with Rollup patches approximately twice a year. As of today we're at ICAN 5.0.5 Rollup 7.

2005: In August 2005 SUN acquired SeeBeyond.

2006: Java Composite Application Platform Suite (CAPS) 5.1.0 This is the first release of the suite after SUN acquisition. The runtime is based on SUN Application Server 8.0. The deployement and monitiring architecture is enhanced.

2007: The last release of the 5.1.x line is 5.1.3. This release continues to be supported and update with Rollup patches approximately twice a year. As of today we're at 5.1.3 Rollup 2.

2008: Java CAPS 6.

history history Delete
type-general type-general Delete
seebeyond seebeyond Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.