This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Re: Autonomous Services
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.
Following my article in the Architecture Journal, I've been getting quite a stream of emails asking for more information. The latest one came from Alex and I'd like to relate his thoughts here, with my comments inserted inline.
"Udi,
I read with big interest your article in the architecture journal. I liked
your ideas, but some statements were not exactly clear to me. In other cases
I thought that clarification may be helpful. I understand you will have lots
of mail to go thru after this publication, but still hope to get your
response and will really appreciate it. So to the point:
1. You are saying "When services interaction is asynchronous we avoid
changing data in other services altogether". The example you were discussing
is using the service B without changing its state so in this case no
transaction will have to include the service B. But if the data on service B
has to be modified I am not sure how this can be implemented asynchronously
(the way you define it) with publishing the state of service B to service A
and storing a subset of this state there. If the operation results in
changing the state of the service B, then how will using the local copy of
the data on service A accomplish the same?"
I'd like to address your first question first. "But if the data on service B
has to be modified I am not sure how this can be implemented asynchronously..." The answer is in the form of a question. Does the data in service B HAVE to be modified? What if we divided up the responsibilities between our services in such a way that all transactional behavior would be local to a single service; long running, inter-service workflows are not transactional end to end. This is one of the practical bits of guidance that gives you feedback on the quality of your service partititioning. This is essentially the answer to your second question too. The operation will not require changing the data in service B, by design.
"2. I think the pattern you were discussing should emphasize the reliability
of delivering the update notifications to the subscribers. In case of
synchronous call the error can be easily detected by the caller and handled
accordingly. In broadcasting model you were discussing the delivery of the
messages must be guarantied by the framework."
Reliability is a big topic. I've posted on the topic before and you can find the summary here. There really are two parts to the reliability of notifications. Consider a smart client that is subscribed to a service which sends it stock updates once a second. When the user turns off his computer, should all those stock updates sent from then until he turns his computer on again be lost or not? What if it wasn't a smart client, but a different service? What if wasn't stock updates, but the results of certain actions requested earlier? It really does depend on the scenario.
However, the point that you bring up about handling errors when communication is fully asynchronous is a good one, and a topic for a separate post.
"3. It may be obvious but I think it is worth mentioning that a service
publishes only the items that changed their state (added, modified,
deleted)."
Again, I'm not sure such a broad statement would hold. Certain data is published in aggregates where, even if certain branches are unaffected, the entire aggregate is sent. This especially holds true for reference data that legacy systems may not have stored locally. Desigining a quality service contract is difficult, and goes hand in hand with properly assigning responsibility to various services.
Well, Alex, I hope that covers your questions. If something still is a bit unclear, feel free to fire me an email to Blog@UdiDahan.com.
Previous Topic
