2008/10/17 Rob Eamon <[EMAIL PROTECTED]>:
> --- In [email protected], "Patrick"
> <[EMAIL PROTECTED]> wrote:
>>
>> [snip]
>
>> ...but there are significant architectural challenges in achieving
>> the correlation of thousands-of-events,
>
> Hmm. Enterprise architecture-wise, it seems almost trivial. The
> components of the architecture simply need to produce/consume events.
> Changing implementations to get the technical components to create
> the events seems to be the hard part.

Theoretically you are correct, practically the problem that Patrick
mentions is a complete and utter bugger.

Non-repudiation, correlation, "lost" events are all a pain at large scales.

>
>> and once you are in a
>> position to correlate those events, some great opportunities for
>> optimising business processes are opened up. I guess if you see a
>> need for CEP within an organisation, then architecturally that
>> requirement is best met by designing in from the ground up. Put
>> another way, retrofitting CEP is (often) a serious challenge.
>
> IMO, CEP is not a "requirement." It is a solution approach. The
> requirement would be something along the lines of identifying
> correlations or relationships amongst the various business
> activities. EDA would be one architectural approach to addressing
> that, with CEP as an implementation approach.

I think the question is what is architecture.  At a B-SOA level its
not an issue, if however you have built a technology infrastructure
around Web Services (or REST) and want to shift towards CEP and some
sort of heuristic filtering then its going to be a bit of a bugger.

Its about the levels of architecture that makes it easy or hard.

Steve

>
>> I've used pass-by-reference (aka out-of-band messaging) approaches
>> to solve architectural issues where the event itself (and key meta
>> data) was important,
>
> What level of architecture do you mean? I assume at the integration
> or application level, rather than the enterprise level.
>
> [snip]
>> I don't see pass-by-reference as a violation of
>> EDA architectural principles - it is actually one of the documented
>> EDA architecture patterns where I work
>
> +1, though IMO it isn't an architecture level issue, it is an
> implementation detail. At the architecture level, one component
> simply sends the event to the consumer(s). The specifics of how that
> is achieved (all at once or via notification/go-get-it) is a detailed
> design concern. An optimization, if you will, much like violating 3NF
> in a DB for efficiency.
>
>> Can you expand on this a bit more? EDA has been around since pretty
>> much the dawn of time in technological terms - at least 15 years -
>> do you perhaps mean the marriage of EDA & SOA, or CEP specifically?
>
> Do you view CEP as an architectural notion?
>
> -Rob
>
> 

Reply via email to