tag:blogger.com,1999:blog-29701096.post116152892675134126..comments2023-10-30T08:55:18.553+01:00Comments on SOA and EDA: The worldwide pitfall of SOAJack van Hoofhttp://www.blogger.com/profile/10073941747649739657noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-29701096.post-1164474199756913982006-11-25T18:03:00.000+01:002006-11-25T18:03:00.000+01:00Hi Dan,Thanks for your comments.Of course these pr...Hi Dan,<BR/><BR/>Thanks for your comments.<BR/><BR/>Of course these principles always must be challenged with practical feasibility when applied to specific situations, as always must be with architectural principles.<BR/><BR/>Most important is to distinguish between the two patterns and think over subtle and skillful what is most appropriate in a specific situation. Be aware of being able to choose and know very well what pitfalls to avoid.<BR/><BR/>In another posting on this subject (<A HREF="http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html" REL="nofollow">How EDA extends SOA and why it is important</A>) I give some guidelines in choosing the right pattern for a given situation.<BR/><BR/>And you might find <A HREF="http://soa-eda.blogspot.com/2006/11/why-to-distinguish-between-soa-and-eda.html" REL="nofollow">this one</A> interesting as well. <BR/><BR/>JackJack van Hoofhttps://www.blogger.com/profile/10073941747649739657noreply@blogger.comtag:blogger.com,1999:blog-29701096.post-1164472206749184792006-11-25T17:30:00.000+01:002006-11-25T17:30:00.000+01:00I agree with your arguments in favor of event driv...I agree with your arguments in favor of event driven architectures, but there are a few points in your posting that I see as challenges.<BR/><BR/>First, coupling can occur at many levels. SOA promises to decouple implementations. By hiding implementation details behind well defined interfaces, you isolate components from implementation details. Service calls do remain coupled at the deployment level though. Two components that interact via SOA have coupled many aspects of their deployments (availability, geographic nearness, performance, etc).<BR/><BR/>Event driven architectures can deliver both interface and deployment decoupling. There are some challenges though as you move to large data sets. Publishing copies of all data to multiple consumers becomes a bottleneck itself. Business processes may also need second order data that isn't directly tied to the event.<BR/><BR/>Looking at an example, if you publish information about a transaction between two parties. The event is really about the transaction. Consumers though will probably need information about the parties involved as well. Do you include that in th event? If so, how much? Just the primary user information or also their derived data?<BR/><BR/>EDA is absolutely more desirable than SOA, but questions such as these often drive more coupling back into EDA than you would like.Anonymousnoreply@blogger.com