Heard what Gartner said back in 2005 (or was it earlier)?
- The best designers of SOA applications are the architects that understand EDA
- Learn EDA to best understand SOA
When I read all those SOA articles and hear all those SOA-gurus talk enthusiastically I see only part of the story, and unfortunately not the most promising part. I'm not sure if those gurus are driving us to deliver the right - or better: complete - designs yet. When they tell you about "calling services" they think RPC-style and that is old-style. The thing is that we have to think in events, even if we decide to implement a request/reply call-stack. To be able to judge when to "call a service" in stead of publishing an event, you need to know EDA. Events are the starting point of the design, the services are not. You don't agree? Well, than you are an old-style developer.
Did you ever notice that EDA is an inverse of RPC-style SOA? (RPC-style SOA, may I nowadays call that SOA 1.0 since the raise of SOA 2.0, huh?) Okay: in EDA the data-supplier takes the initiative in contrast to RPC-SOA where the consumer does. In EDA the supplier and consumer do not know anything of each others existence, they are decoupled. On the other hand in RPC-SOA the consumer calls the supplier by name and even waits for a reply. If the reply doesn't come, the consumer falls into an error procedure; that really is tightly coupled, isn't it? Not in your case? You use asynchronous queues to perform service requests? Well, you are tricking around, probably for good reasons, but it is not EDA; EDA is asynchronous by nature, you can't trick it to act synchronously. EDA has focus on data (message) while RPC-SOA has focus on function (service). Want more? EDA is declarative while RPC-SOA is procedural. That is in EDA you can tick to connect events to processes; in RPC-SOA you built algoritms with If-Then-Else and DoCase constructs in order to fire the appropriate calls. You don't agree? Okay, old-style developer.
What about granularity? How big must a service be? Our SOA-gurus say: not too big and not too small. Depending on what? Some gurus say: depending on performance. I think they are mixing up services which are functional components, and "Web Services" which is an interface implementation technology. To me it makes more sense to ask at which levels of granularity the use of web services technology is appropriate. And that depends on system implementation characteristics such as degree of distribution and heterogeneity and desired openness. So in fact there is no conceptual granularity-issue. You start - top down - designing focused on business events, which are events with business significance. When you reach a level too fine grained to recognize neat real-world events you leave the business oriented approach and enter the application oriented approach where RPC-SOA may become adequate. This is the level to compose adaptive business solutions - i.e. ways to handle business events - using independent generic components. So at this level you start creating SOA building blocks to construct modular applications. Though, that doesn't mean you must drop the even-driven paradigm here, preferably not. Don't agree? You old-style delevoper.
As you might have read between the lines, EDA has affinity with business processes and SOA has affinity with application construction. Taking into account that the EDA approach is an inverse of the well known SOA approach you might say the two paradigms are complements by nature.
Do you recognize the huge business potential of asynchronous, event oriented design? And do you believe that EDA by its nature will be the paradigm to realize the ultimate alignment of business processes and the supporting IT-systems? That the ultimate layer between our real world-events and artificial application constructs will be an EDA? And do you recognize the possibilities offered by the current IT-technology evolutions to support this paradigm? Then you truly are a new-style developer.
Posts
No comments:
Post a Comment