|
August 2007
August 31, 2007
[Podcast] Using Autonomous Components for SLAs in SOA
In this podcast we answer questions about how to use autonomous components to unify disparate building blocks like servers, middleware, and databases in order to handle the technical complexity of complying with detailed service-level agreements. Reuse of business logic, database schemas, and messaging topics between autonomous components are discussed as well.
Download via the Dr. Dobbs' site
And here's this week's question:
Hi Udi,
Thanks again for your continued assistance. I was very much interested by your advice to consolidate each of the services related to each product family into a single service, but as autonomous components.
From your description of autonomous components from a prior podcast, it seems that they are much the same as services - in that they communicate only via loosely coupled messaging, and can have their own databases. Would you say that the main difference between autonomous components is that different autonomous components within a service may in fact share business logic and databases? If so, it would seem that combining these services into a single service with 3 autonomous components would be a matter of definition, rather than an architectural shift. Any information you could provide to clarify this distinction would be fantastic.
Something else that's been playing on my mind of late - is whether or not you would consider a topic as having to belong to a specific service. That is, would you say it is bad practice to have multiple services publish on a common topic? I suppose if we have multiple services publishing on a common topic, then they should be defined as autonomous components, belonging to a single larger service - in which case that common topic would belong to that new service.
As usual your advice is always extremely helpful. Please keep those podcasts coming!
Best Regards,
Bill
Additional References
Posted by Udi Dahan at 02:35 AM Permalink
|
August 16, 2007
[Podcast] Handling Dependencies Between Subscribers in SOA
In this podcast we answer questions about how to solve dependencies between systems that subscribe to events in SOA. We'll also get into the pitfalls of employing distributed transaction when reusing existing systems even behind service boundaries.
Download here
And the original question was:
Udi:
I have a question regarding publishing events that relate to data changes. I found the article you wrote in the Arch Journal #8 very helpful. I think striving for autonomy is very important. The scenario I was thinking about is how can you ensure synchronization across subscribers of a particular event.
For example, System A publishes an event when customer information is updated. There are several systems that subscribe to this event. Two of the systems, System B and System C, need to be sync regarding customer information. System B uses operations from System C using the customer data. Using your example, System B has a process that runs for all "Preferred Customers", and it uses processes on System C. However, System C may not have process the event to and may have a customer as preferred.
I have several thoughts, but would like to get your thoughts on this scenario. Are there any best practices or patterns?
Phil
Additional References:
You can find more episodes like this in the Ask Udi archives.
Posted by Udi Dahan at 07:48 AM Permalink
|
August 14, 2007
.NET/Java Interop is not a reason for SOA
I see this all too often.
A company has some legacy (read "good") code in one platform (let's just use Java for this example). This company has now decided to standardize on the other platform (Microsoft's happy). The company doesn't want to throw away and/or rewrite the assets they already have from the previous platform.
What do they do?
Web Services, of course!
Obviously this has to be a part of the "grand" SOA effort currently under way. Here's a chance to build some reusable services, right?
The only problem is that in order for things to work right they (sometimes, but way too often) implement a chatty interface between the two platform-oriented services and flow transaction contexts between them as well as use other poor practices.
So, what's the solution?
Well, Web Services isn't the only kind of interop out there. Take a look at what the guys from MainSoft are doing. Not only does it work, it's been working for years now. You can go the other way too - run .NET code on JVM based application servers. And there are more solutions out there. There's JNBridge (with some nifty online demos), and EZ JCOM who also do COM interop.
Bottom line, there are good technical solutions out there for reusing and interop-ing with assets from multiple platforms. Therefore, now that we've slain the holy cow of interop, there is absolutely no good reason or justification to create tightly coupled services.
Period.
Posted by Udi Dahan at 04:09 PM Permalink
|
August 12, 2007
DevHawk not thrilled about Astoria either
It appears that more people are coming to the same conclusions that I have about Astoria (Astoria, SDO, and Irrelevance), Microsoft's new "Data Services for the Web" initiative.
DevHawk (aka Harry Pierson) writes:
As you might guess then, I’m not a fan of Astoria. I believe the sweet spot for so called “data services” will be read only (because they don't need transactions, natch). I'm sure there are some read/write scenarios Astoria will be useful for, but I think they will be limited - at least within the enterprise.
After catching up to Pablo Castro (the man behind Astoria) at DevTeach, and chatting with him and Tim Mall about Astoria, I heard something interesting. In order to provide business context for updates, you will be able to use something like a WS-Action header.
So, it's based on REST, but for updates, it's like WS-*. Hmm... Best of both worlds, or worst? What do you think?
Posted by Udi Dahan at 03:34 PM Permalink
|
|
