Artwork

Treść dostarczona przez Udi Dahan. Cała zawartość podcastów, w tym odcinki, grafika i opisy podcastów, jest przesyłana i udostępniana bezpośrednio przez Udi Dahan lub jego partnera na platformie podcastów. Jeśli uważasz, że ktoś wykorzystuje Twoje dzieło chronione prawem autorskim bez Twojej zgody, możesz postępować zgodnie z procedurą opisaną tutaj https://pl.player.fm/legal.
Player FM - aplikacja do podcastów
Przejdź do trybu offline z Player FM !

[Podcast] Using Autonomous Components for SLAs in SOA

 
Udostępnij
 

Manage episode 65045193 series 63841
Treść dostarczona przez Udi Dahan. Cała zawartość podcastów, w tym odcinki, grafika i opisy podcastów, jest przesyłana i udostępniana bezpośrednio przez Udi Dahan lub jego partnera na platformie podcastów. Jeśli uważasz, że ktoś wykorzystuje Twoje dzieło chronione prawem autorskim bez Twojej zgody, możesz postępować zgodnie z procedurą opisaną tutaj https://pl.player.fm/legal.

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.

Or download directly here.

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

  continue reading

21 odcinków

Artwork
iconUdostępnij
 
Manage episode 65045193 series 63841
Treść dostarczona przez Udi Dahan. Cała zawartość podcastów, w tym odcinki, grafika i opisy podcastów, jest przesyłana i udostępniana bezpośrednio przez Udi Dahan lub jego partnera na platformie podcastów. Jeśli uważasz, że ktoś wykorzystuje Twoje dzieło chronione prawem autorskim bez Twojej zgody, możesz postępować zgodnie z procedurą opisaną tutaj https://pl.player.fm/legal.

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.

Or download directly here.

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

  continue reading

21 odcinków

Wszystkie odcinki

×
 
Loading …

Zapraszamy w Player FM

Odtwarzacz FM skanuje sieć w poszukiwaniu wysokiej jakości podcastów, abyś mógł się nią cieszyć już teraz. To najlepsza aplikacja do podcastów, działająca na Androidzie, iPhonie i Internecie. Zarejestruj się, aby zsynchronizować subskrypcje na różnych urządzeniach.

 

Skrócona instrukcja obsługi