Artwork

Innhold levert av Udi Dahan. Alt podcastinnhold, inkludert episoder, grafikk og podcastbeskrivelser, lastes opp og leveres direkte av Udi Dahan eller deres podcastplattformpartner. Hvis du tror at noen bruker det opphavsrettsbeskyttede verket ditt uten din tillatelse, kan du følge prosessen skissert her https://no.player.fm/legal.
Player FM - Podcast-app
Gå frakoblet med Player FM -appen!

[Podcast] Message Schemas Between Multiple Publishers and Subscribers

 
Del
 

Manage episode 65045196 series 63841
Innhold levert av Udi Dahan. Alt podcastinnhold, inkludert episoder, grafikk og podcastbeskrivelser, lastes opp og leveres direkte av Udi Dahan eller deres podcastplattformpartner. Hvis du tror at noen bruker det opphavsrettsbeskyttede verket ditt uten din tillatelse, kan du følge prosessen skissert her https://no.player.fm/legal.

This week’s question comes from Bill who asks:

Thanks again Udi for your informative response. I have been having more and more continued success leveraging service oriented design principals in my work. My client is thrilled with the result – systems that work and are agile! 🙂 Your advice over the last number of months has been a big ingredient in that success.

As per usual, I have another question I was hoping I could trouble you with. I have a service which needs to subscribe to a topic which is a parent topic in a topic hierarchy.

Say I have 3 different families of insurance products, each of which have a “Policy Written” event. So we would have:

Product Family 1 Policy Written
Product Family 2 Policy Written
Product Family 3 Policy Written

These 3 messages have some information in common – such as Policy Number, Product Code, Date Written, etc. I’d like to be able to add more products with their own unique “Policy Written” event, without altering the service subscribing to the “Policy Written” topics. This means that the subscribing service would need to know about the “Policy Written” base type of message, without knowing about the specific sub types. Assuming the messages are serialised using SOAP/XML, would you recommend achieving his using XML data type inheritance? So each of the message sub types would inherit from a message base type? Or would you recommend just having the subscribing service understand each message sub type, and update it as new sub types are added? Or is there another solution you could offer?

I can see that having the base message type increases coupling between publishing services because each service that publishes a Policy Written event must adhere to the base message type schema. But I can also see having the subscribing service understand all message sub types increases coupling between the subscribing service and the publishing services because adding a new insurance product requires modifying the subscribing service to understand the new message sub type.

Regards,
Bill

Get it via the Dr. Dobb’s site here.

Or download directly here.

Additional References:

Podcast on Autonomous Services and Pub/Sub
Podcast on Business and Autonomous Components in SOA

Want more? Go to the “Ask Udi” archives.

  continue reading

21 episoder

Artwork
iconDel
 
Manage episode 65045196 series 63841
Innhold levert av Udi Dahan. Alt podcastinnhold, inkludert episoder, grafikk og podcastbeskrivelser, lastes opp og leveres direkte av Udi Dahan eller deres podcastplattformpartner. Hvis du tror at noen bruker det opphavsrettsbeskyttede verket ditt uten din tillatelse, kan du følge prosessen skissert her https://no.player.fm/legal.

This week’s question comes from Bill who asks:

Thanks again Udi for your informative response. I have been having more and more continued success leveraging service oriented design principals in my work. My client is thrilled with the result – systems that work and are agile! 🙂 Your advice over the last number of months has been a big ingredient in that success.

As per usual, I have another question I was hoping I could trouble you with. I have a service which needs to subscribe to a topic which is a parent topic in a topic hierarchy.

Say I have 3 different families of insurance products, each of which have a “Policy Written” event. So we would have:

Product Family 1 Policy Written
Product Family 2 Policy Written
Product Family 3 Policy Written

These 3 messages have some information in common – such as Policy Number, Product Code, Date Written, etc. I’d like to be able to add more products with their own unique “Policy Written” event, without altering the service subscribing to the “Policy Written” topics. This means that the subscribing service would need to know about the “Policy Written” base type of message, without knowing about the specific sub types. Assuming the messages are serialised using SOAP/XML, would you recommend achieving his using XML data type inheritance? So each of the message sub types would inherit from a message base type? Or would you recommend just having the subscribing service understand each message sub type, and update it as new sub types are added? Or is there another solution you could offer?

I can see that having the base message type increases coupling between publishing services because each service that publishes a Policy Written event must adhere to the base message type schema. But I can also see having the subscribing service understand all message sub types increases coupling between the subscribing service and the publishing services because adding a new insurance product requires modifying the subscribing service to understand the new message sub type.

Regards,
Bill

Get it via the Dr. Dobb’s site here.

Or download directly here.

Additional References:

Podcast on Autonomous Services and Pub/Sub
Podcast on Business and Autonomous Components in SOA

Want more? Go to the “Ask Udi” archives.

  continue reading

21 episoder

Semua episod

×
 
Loading …

Velkommen til Player FM!

Player FM scanner netter for høykvalitets podcaster som du kan nyte nå. Det er den beste podcastappen og fungerer på Android, iPhone og internett. Registrer deg for å synkronisere abonnement på flere enheter.

 

Hurtigreferanseguide

Copyright 2024 | Sitemap | Personvern | Vilkår for bruk | | opphavsrett