Tim Bass
Lundi, 02 Jun 2008 08:43:56 +0000

En réponse à Paul Vincent * post CEP est un service ou un processus?* I posted CEP est un service ou un processus? Reloaded.* Ce poste est un suivi de mon dialogue avec Paul et le SCEP communauté dans son ensemble.
Parmi les plus remarquables des commentaires critiques sur le livre "The Power of Events" était que le livre n'a pas (pour la plupart) * discuter de l'architecture .*
Comme nous le savons tous, il existe de nombreuses définitions de "l'architecture"; toutefois, une définition * est facile de discuter, dans ce contexte, est que les systèmes de TI * une "architecture" représente les composants d'un * IT * * et le système relations entre les différents composants * dans l'architecture .*
Une architecture peut être "technique" ou "fonctionnel" ou "opérationnels" ou * "données" centrées .* Par exemple, l'architecture peut être fondée sur une orchestration de service * composantes, comme une SOA .* Dans un autre exemple, un l'architecture peut être représentée par la sémantique des données .* Dans un autre exemple, une architecture peut être représentée par la fonctionnalité des composants.
Parce que le livre de David sur le CEP n'a pas abordé l'architecture, les gens sont libres d'utiliser n'importe quel "outil" ou "technique" qu'ils aiment, et l'appeler "CEP" .** Mon attention a été portée sur l'ensemble de la fonctionnalité et la CEP architectures de référence qui décrivent cette fonctionnalités pour résoudre CEP classes de problèmes.
Cela a été un des premiers sujets (questions) * * avec le CEP nous avons identifié il ya quelques années, et * est pourquoi, nous, y compris à moi * * * ma bonne ole 'TIBCO à jour jusqu'à maintenant, a créé une architecture fonctionnelle de référence pour le PEC (également dans ce blog et le blog TIBCO CEP).
Dans cette architecture fonctionnelle de référence, nous avons discuté et illustré * * CEP comment devrait fonctionner comme une coopérative (distribué) l'architecture fonctionnelle de référence pour résoudre la plupart des "vrais" CEP classes de problèmes.
Par conséquent, * CEP ne devrait pas être, de manière générale, * considéré comme un «processus» ou un «service» *, en soi, parce que * ** CEP, comme une architecture de référence * fonctionnelle, dépeint les méthodes (functionaility) nécessaires à la résolution de complexe, axée sur la détection des problèmes .* Ce résumé CEP permet d'avoir un sens dans le contexte plus large des applications de traitement de l'événement.
Naturellement, une architecture fonctionnelle de référence peut être considérée comme un "service" si tous les composants dans l'architecture de coopérer pour résoudre un problème et sont encapsulés en tant que service .* En outre, une architecture fonctionnelle de référence peut être considéré comme un «processus» lorsque résoudre les problèmes dans un domaine spécifique .* Ainsi, un "processus", dans ce cas, est un exemple de l'architecture fonctionnelle de référence, et si l'instance est emballé comme une solution, cette solution peut être résumée comme un service.
Ainsi, il est trompeur, du moins à mon avis, * réduire CEP à un "processus" ou un "service" à moins que nous discutons d'une solution à un problème dans un domaine (fonctionnel) architecture de référence (contexte fonctionnel).
* Cette confusion se manifeste dans le débat animé entre Mark Palmer et la blogosphère en ce qui concerne la maturité du CEP .** Mark et d'autres ont créé une instance de l'événement de transformation des marchés de capitaux et de l'appeler "CEP", alors qu'en fait, ce qu'ils font est COTS algo de négociation et en utilisant un ou plus de composants fonctionnels du CEP à réaliser leur solution.
La distinction est importante, à mon avis.



Source ...