This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Me and my Shadowfax
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
I'm very pleased to see that my thoughts about entities have made it in. A special hats off to the team for finding a better name for my PersistenceService - now called Entity Services. In hindsight, its obvious that there needs to be more than one low level service for dealing with entities.
"Entity Services represent simple atomic operations on an entity like orders, accounts, customers etc. May write directly to store or component, external partner or legacy system."
Now, the services exposed by the Entity Services aren't to be exposed to the world. They are too low-level, and have no business value. That's why there needs to be another service above ( around ? ) them. What I previously called the BusinessService is now referred to as Activity Services. Again, it only makes sense that there be more than one if necessary.
"Activity services coordinate the operation of several Entity Services into a single atomic operation (UpdateCustomer, AcceptPO)".
These services are ready for prime time - at the single system level anyway. It makes perfect sense for a system to expose these services for consumption by other systems in the enterprise. On the other hand, I don't think that they are so suited to be exposed to external partners.
For this reason, there are Process Services. "Process services represent long running business processes that may involve complex workflow and human interaction". This is an area that I have to give some more thought to, from an implementation perspective. Specifically, how the Business Rules Services interact with the Process Services. It is fairly clear ( to me, at least ) how the Business Rules Services work in concert with the Activity Services. So, I'll have to see how to resolve these issues.
All in all, I think that Shadowfax is going in the right direction. I specifically like the way that all of this sits with developing a single system. There has been much ado about nothing on the whole "SOA is about integrating different systems vs SOA is about how to build one system" debate. I'm glad to see that Shadowfax has taken the high road.
Previous Topic
