Additional SOA Patterns –Supporting Composition Controllers - Applied SOA Patterns on the Oracle Platform - page 576

So, it appears that we, in fact, have the data format and model declarations in an XML
form for the event, and we put some effort into adapting the inbound flows to our underly-
ing component. Thus, the Adapter Framework is essential in EDN, and dependency in-
jection can be seen here as a form of dynamic Data Model/Format Transformation of
the object's data. Going further, just following the SOA reusability principle, a single ad-
apter can be used in multiple event-processing networks and for that, we can employ the
Adapter Factory pattern discussed earlier (although it's not an official SOA pattern, re-
member?) For that, we will need the Adapter Factory class and the registration of this
factory in the EPN assembly file with a dedicated provider name, which we will use fur-
ther in applications, employing the instance of this adapter. You must follow the OSGi
service registry rules if you want to specify additional service properties in the
<osgi:service inter-
face="com.bea.wlevs.ede.api.AdapterFactory"> section and register it
only once as an OSGi service.
We also use Asynchronous Queuing and persistence storage to provide reliable delivery
of events aggregation to event subscribers, as we demonstrated in the previous paragraph.
Talking about aggregation on our CQL processors, we have practically unlimited possibil-
ities to merge and correlate various event sources, such as streams:
<query id="cargoQ1"><![CDATA[
select * from CragoBookingStream, VoyPortCallStream
where CragoBookingStream.POL_CODE =
VoyPortCallStream.PORT_CODE
and VoyPortCallStream.PORT_CALL_PURPOSE ="LOAD"
]]></query>
Here, we employ Intermediate Routing (content-based routing) to scale and balance our
event processors and also to achieve a desirable level of high availability. Combined to-
gether, all these basic SOA patterns are represented in the Event-Driven Network that
has Event-Driven Messaging as one of its forms.
Simply put, the entire EDN has one main purpose: effective decoupling of event (mes-
sage) providers and consumers (Loose Coupling principle) with reliable event identifica-
tion and delivering capabilities. So, what is it really? It is a subset of the Enterprise Ser-
vice Bus compound SOA pattern, and yes, it is a form of an extended Publish-Subscribe
pattern .