IPF 2.0.0

Added by Martin Krasser, last edited by Boris Stanojevic on Nov 05, 2009  (view change)

Downloads

File Content
ipf-2.0.0-bin.zip
  • IPF binaries
  • IPF dependencies
  • IPF reference manual
  • IPF javadocs
ipf-2.0.0-bin-nodeps.zip
  • IPF binaries
  • IPF reference manual
  • IPF javadocs
ipf-2.0.0-src.zip
  • IPF sources

Release notes

This release is feature-equivalent to IPF 1.7.0 but runs on Camel 2.0. Users who plan to upgrade to IPF 2.0 or Camel 2.0 in the near future are highly recommended to use this milestone release. Please note that IPF 2.0 is not backwards-compatible to IPF 1.x. This is mainly due to non-backwards compatible API changes in Camel 2.0. It is therefore important to carefully read the Camel 2.0.0 release notes as well as the upgrade notes section on this page.

With the release of IPF 2.0.0 and IPF 1.7.0, IPF 1.x development will go into maintainance mode and new features will be developed on the IPF 2.0 development branch. We leave it open whether to backport selected IPF 2.x features to IPF 1.x. Please add any backport requests to the IPF issue tracker.

Other changes compared to IPF 1.7.0 are:

Over the last weeks we also had several discussions regarding project structure and package name changes. We finally dropped these intended changes from our plan because we considered ease of upgrade to IPF 2.0 more important. The existing structure is sufficiently clear and modular to easily support the addition of new IPF features.

Changes since 2.0-m2

Category Changes
New feature
Other  

Feature overview

Here's a brief overview of the IPF 2.0.0 features.

Feature Description
Apache Camel IPF is based on Apache Camel. For an overview of Camel's rich feature set (which can be fully used in IPF applications) refer to the project's integration patterns and integration components pages.
Groovy scripting layer With IPF you define integration routes with the Groovy programming language. It is more than a mere usage of Camel's domain-specific language (internal DSL or fluent API) inside Groovy: Camel's native DSL has been extended to support e.g. the usage of closures (for inline definitions of message processors, routing rules etc.) and also provides a DSL extension mechanism to define custom extensions to the Camel DSL.
DSL extension mechanism The DSL extension mechanism is a Groovy meta-programming-based mechanism for defining new DSL elements to be used in integration routes. This is especially useful if you want to provide custom language elements for re-occurring message processing patterns or if you want to design a project-specific message processing DSL (e.g. one that is related to the HL7 domain).
DSL extension index An index of all predefined DSL extensions provided by IPF.
Core features These are domain-neutral message processors and DSL extensions usable for general-purpose message processing. The core features also enhance existing Camel DSL elements for usage with Groovy-specific language elements such as closures. For XML message processing there is special Groovy XML support.
HL7 message processing Basis for HL7 message processing is the HL7 DSL, the HAPI extensions and the HL7 validation DSL. These provides the basis for implementing HL7 message processing routes.
IHE support A set of components for creating actor interfaces as specified in IHE profiles. IPF currently supports creation of actor interfaces for the IHE profiles XDS.a, XDS.b, PIX and PDQ.
CDA support A domain-specific language for building and navigating CDA documents. This DSL supports the creation of structurally correct CDA documents by enforcing CDA-relevant schema definitions but without dealing with low-level XML details.
Flow management A platform service to monitor, query, audit, replay and cleanup message flows. The management interfaces are based on JMX.
OSGi support Enables the deployment of IPF components (bundles) to OSGi platforms. IPF service bundles register platform services at the OSGi service registry for consumption by IPF applications. Extender bundles control the activation of DSL extensions inside an OSGi environment. A reference implementation of IPF on top of Eclipse Equinox is available as IPF runtime in the IPF Tools project. This project also maintains the complete IPF OSGi documentation.
Event infrastructure An infrastructure for unified publishing of system-events and application-events. Subscriber components can be configured to translate application events to e.g. Atom/RSS feeds or log files to mention a few.
Performance measurement DSL and tools to determine the performance characteristics of IPF applications. These allow for measuring the processing time of messages for routes or route parts as well as the message throughput. Performance measurement results can be viewed with a web browser.
Large message support Provides memory efficient processing of messages with large content sizes.
Quality of service IPF provides extensions, guidance and solution blueprints (code examples) for implementing non-functional requirements. Covered topics are transactional messaging, flow management, load-balaning and high-availability.
Module adapters An infrastructure for including platform-independent message processing libraries into platform-specific message processing routes. An alternative is Camel's bean integration mechanism.
Tutorials A bunch of tutorials that help you get started with IPF.
Guidelines Guidelines for IPF application development. For example, the DSL extensions guide describes how to write you own DSL extensions.
Project templates Maven archetypes for most commonly used IPF project types, ranging from simple embedded integration solutions to cluster configurations supporting high-availability scenarios. Usage examples of IPF features are provided as well.

Upgrade notes

Before reading the IPF 2.0 upgrade guide make sure you also read the Camel 2.0.0 release notes.

Known issues

  • IPF 2.0 uses Spring 2.5.6 (included via Camel 2.0). This version has a major bug in the spring-jms component that affects routes that use the Camel JMS component. This bug may cause IPF applications to hang in shutdown phases. So far, we didn't observe any issues during normal operations of JMS-based routes.
  • Due to a bug in CXF, XDS.b consumer components send all responses in SOAP 1.2, even when corresponding requests used SOAP 1.1.
  • Due to a CXF issue the ITI-43 implementation can lose attachments in the response (client side) if the client is heavily multi-threaded. This happens with version CXF 2.1.3-2.1.6 (as used by Camel 1.x) and with CXF 2.2.2 (as used by Camel 2.x).
  • Repository unique ID in ATNA logging for XDS is wrong due to an OHT issue

Further notes

  • Javadocs for Groovy sources have been generated from Java 'stubs' which have been derived from the Groovy sources via the gmaven-plugin.
  • Source cross-references also include Java 'stubs' which have been derived from the Groovy sources. These sources do not represent the logic implemented in the Groovy source files.
  • Source jars deployed to the Open eHealth Maven repository also include Java 'stubs' which have been derived from the Groovy sources. These sources do not represent the logic implemented in the Groovy source files.

Documentation

Getting started

Reference manual

Tutorials

Reports

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.