Index Changes

Difference between version and version     

Back to Fuji EIP Aggregate, or Fuji EIP Aggregate Info


At line 1 changed 2 lines.
!!! Enterprise Integration Patterns - Aggregate
[{Image src='fuji-logo8.gif' link='https://fuji.dev.java.net/' alt='Fuji Home' align='left'}]
!!!Enterprise Integration Patterns - Aggregate
At line 33 changed 1 line.
type := aggregate implementation (e.g. set, select)
type := aggregate implementation (e.g. set, java)
At line 43 changed 1 line.
aggregate set {count=5}
aggregate set ("count=5")
At line 62 removed 1 line.
At line 64 changed 12 lines.
Each aggregate type will have its own unique configuration requirements. The service artifact layer in Fuji will have a reasonable default behavior for all aggregate types. Individual aggregate types can override the default behavior by implementing the following contracts:
* Generation - the configuration generated from IFL for a given aggregate type. A facility must exist for discovering template service artifacts for a given aggregate type. This could be an SPI or a convention for resource location inside a bundle/jar file. For external configuration, a default implementation should be provided that results in an empty file with the aggregate configuration name used as the file name. Generation is not relevant for inline configuration.
* Validation - during the packaging phase of the application build, aggregate types will have an opportunity to validate configuration. This should be exposed as an SPI that a aggregate type provider can implement.
\\
The directory layout for generated configuration should be:
{{{
app-root/
aggregate/
{name}/
[configuration]
}}}
Where '{name}' is the named configuration provided in IFL.
Each aggregate implementation will have it's own specific configuration. There however is configuration which can be defined for all types in general. This being:
At line 77 changed 8 lines.
! Set
The ''set'' type provides for aggregation of input messages as a set. The configuration of ''set'' allows the user to define the conditions under which a set is complete and messages in the set are forwarded on as a single, aggregated message. The following configuration options are supported:
* ''size'' : the size threshold for aggregated messages. Once the threshold is reached, all messages in the set are aggregated. Valid units are 'mb', 'kb', and 'b' (e.g. 10mb = 10 megabytes).
* ''count'' : number of messages that must be in the set before they are aggregated into a single message.
* ''wait'' : amount of time to wait before the set is aggregated. Valid units are ms, s, m, h (e.g. 1h = 1 hour).
* ''order'' : specifies the order in which input messages are added to the aggregate message. Valid values are 'created' and 'received'.
* ''header'' : content to be included before the aggregated message content.
* ''trailer'' : content to be included after the aggregated message content.
|| Attribute || Description || Default
|''timeout'' | amount of time to wait before the set is aggregated. Valid units are ms, s, m, h (e.g. 1h = 1 hour).
|''on-timeout''| action to be performed if aggregate timeout interval expires and the aggregate conditions are not met. i.e on-timeout={error,send}| send
|''correlation-id''| This is not yet a configurable parameter, but will be made configurable in the future. Currently the set and java aggregate types infer the correlation id to be the value of the "org.glassfish.openesb.messaging.groupid" Normalized Message property | Value of the "org.glassfish.openesb.messaging.groupid" property
At line 86 changed 1 line.
''NOTE: header and trailer values can be used together to enclose a set of aggregated XML documents within a single parent element.''
!! Aggregate Implementations
At line 88 changed 42 lines.
Input Messages
{{{
<record>
<num>001</item>
<data>Veni</desc>
</record>
}}}
{{{
<record>
<num>002</item>
<data>Vidi</desc>
</record>
}}}
{{{
<record>
<num>003</item>
<data>Vici</desc>
</record>
}}}
Set Configuration
{{{
count=3
header=<records>
trailer=</records>
}}}
Output Message
{{{
<records>
<record>
<num>001</item>
<data>Veni</desc>
</record>
<record>
<num>002</item>
<data>Vidi</desc>
</record>
<record>
<num>003</item>
<data>Vici</desc>
</record>
</records>
}}}
There are two aggregate types supported in the current release:
At line 74 added 4 lines.
* __[set | FujiEIPAggregateSet]__ - out of the box implementation of a Set aggregator.
* __[java| FujiEIPAggregateJava]__ - provides the extensibility to plugin in a user defined POJO for aggregation.
At line 132 changed 1 line.
At application build time, all aggregate configurations should be packaged as part of the application. Since the ultimate consumer of this configuration information is the runtime aggregate implementation, and not a component, it is not appropriate to package the individual configuration instances into a service unit. Rather, the following convention should be followed:
At application build time, all aggregate configurations are packaged as part of the application. Since the ultimate consumer of this configuration information is the runtime aggregate implementation, and not a component, it is not appropriate to package the individual configuration instances into a service unit. Rather, the following convention is being followed:
At line 142 changed 1 line.
All aggregate configuration should be included in this directory, including inline configuration. Since inline configuration is not named, a name must be generated. Using a pattern of 'aggregate$n' should work, where 'n > 0' and increments for each inline aggregate definition in the IFL.
All aggregate configuration is included in this directory, including inline configuration. Since inline configuration is not named, a name must be generated. Using a pattern of 'aggregate$n' should work, where 'n > 0' and increments for each inline aggregate definition in the IFL.
At line 145 removed 1 line.
!! Runtime
At line 148 removed 1 line.

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-16) was last changed on 02-Jun-09 02:04 AM, -0700 by Nikita