various fixes in pom.xml files (removed duplicate dependencies and migrated deprecated properties)
Bundle plug-in now supports capabilities to parse spring configuration files for imports
Java 1.6 now officially required for building ipf (was previously implicitly required by code)
New rule on calculating ipf-bundle versions is deployed. The qualifier is no longer considered to be part of the ImportPackage-Version dependency (only the first three digits)
New Spring (2.5.6.A) and Spring-DM (1.2.0) framework versions deployed
New org.apache.felix.maven-bundle-plugin version 2.0.0 deployed
The behavior of the basic extender changed that it now honors already installed bundles
Improved performance of XSD validator
Improved PIX/PDQ custom HL7 message definitions
Discontinued support of URL parameter soap11 in Web Service-based IHE components
Better support for IntelliJ IDEA to ensure all maven pom files can be used without changes
BidiMappingServiceConfigurer renamed to BidiMappingServiceOsgiConfigurer. BidiMappingServiceConfigurer now used for non-OSGi environments.
Support classes for Web Service-based IHE transactions, previously located in org.openehealth.ipf.platform.camel.ihe.xds.core and org.openehealth.ipf.commons.ihe.xds.core, have been factored out to org.openehealth.ipf.platform.camel.ihe.ws and org.openehealth.ipf.commons.ihe.ws respectively. Moreover, a few CXF interceptors have been renamed to obey a naming convention.
Custom HL7 v2 message definitions for ITI-9 and ITI-21/22 have been moved from platform-camel-ihe-pix-iti9 and platform-camel-ihe-pdq-core to commons-ihe-pixpdq. The accessors by field name (such as QBP_Q21#getWhatDomainsReturned()) have been changed to align with the definition of the standard message structures.
Renamed the DSL extension setProperty to setExchangeProperty (fix for issue #314)
Changes to IHE related artifacts
In order to simplify the project structures in commons/ihe and platform-camel/ihe several projects have been merged and/or moved. Applications using the IHE components of the IPF must be updated to use the new dependencies in their pom files. The following table summarizes these changes:
Old artifact ID
New artifact ID
commons-ihe-xds-*
commons-ihe-xds
platform-camel-ihe-atna-util
platform-camel-ihe-atna
platform-camel-ihe-mllp-core
platform-camel-ihe-mllp
platform-camel-ihe-pdq-*
platform-camel-ihe-pixpdq
platform-camel-ihe-pix-*
platform-camel-ihe-pixpdq
platform-camel-ihe-xds-*
platform-camel-ihe-xds
Feature overview
Here's a brief overview of the IPF 2.1-m2 features.
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.
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.
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).
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.
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, PDQ, PIXv3 and PDQv3.
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.
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.
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.
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.
An infrastructure for including platform-independent message processing libraries into platform-specific message processing routes. An alternative is Camel's bean integration mechanism.
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.
Known issues
IPF 2.1 uses Spring 2.5.6 (included via Camel 2.2). 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.
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.