Ask Udi Podcast – Udi Dahan – The Software Simplist

[Podcast] Migrating from N-Tier to SOA

Udi Dahan — Wed, 05 Dec 2007 21:27:18 +0000

In this podcast we’ll be discussing certain methodologies for migrating an architecture from N-Tier to SOA. We’ll see what parts can be used almost unchanged, and which N-Tier concepts have no place in this new, service-oriented world.

Ketan asks:

Hello Udi,

I am Ketan, working as Analyst Programmer in India. I want some information regarding SOA Architecture. I have visited several blogs and sites and I do have enough knowledge regarding technical terms of SOA. I have worked a lot in 3-tier mechanism a lot and now want to switch on SOA Architecture in Visual Studio 2005.

I read your blog post How to migrate to SOA and liked the contents and am interested in doing it. Can you please be more precise about how to migrate from 3-tier to SOA? Actually, I have read whole content of above link and you have explained enough. But, still I want you to keep me out from dark. You have described it functionally, but I want some technical description of this process. Please help me in this.

If you can provide me some example/application (in which SOA Architecture has been implemented), then it will be very helpful to me.

Thanks in advance. Waiting for your favorable reply.

Ketan

Download

Download directly here.

Additional References

Blog post on migrating from layers to services
Podcast on “Does SOA mean the end of OO”?

Want more?

Check out the “Ask Udi” archives.

Got a question?

[Podcast] Versioning and SOA–There is no IDog2

Udi Dahan — Fri, 09 Nov 2007 09:38:08 +0000

In this podcast we’ll look at the issues around versioning and SOA and how the asynchronous nature of messaging obviates the need for previously accepted interface-based versioning practices.

Jarrod asks:

Hi Udi,

I have some questions around versioning and SOA:

Over the years I’ve been fairly adamant about the practice of versioning interfaces should a method change be needed.

Hence, IDog and IDog2

Generally I would also say that a method addition would need a new interface as much as a change to an existing method or property (sometimes requiring completely deprecating the old interface).

With SOA being used more and contract first designs coming down the pipe…an addition of a method or operation to a contract in SOA does not mean its a breaking change.

So, do you continue to create a new interface and version the name within an SOA environment? Even if its just one method that is being added?

A service contract, in general…with just a single method in my opinion is a bad design. Sure, there are exceptions to that but I can just see changes made to the service contracts over the course of a few years with many 1-2 method interfaces.

Day 1 : 12 methods on interface IDog

6 months later : 1 new method, create IDog2 which implements IDog

15 months later : 2 new methods, create IDog3 which implements IDog2

Some can argue that if you’re having to add methods like this, the original design was flawed. That may be…or you could just be in a volatile business environment in which SOA must adapt.

So my main questions are:

1) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you also have control of the consumers (internal consumers)?

2) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you do not have control of the consumers (external consumers)?

3) If the answer to the above is yes, is a single method on a new interface acceptable?

4) If you know of a problem in an existing interface on a method and have control of the consumers – do you “fix” the method and redeploy to the consumers? Or do you deprecate the entire interface and begin anew?

I’m interested in seeing your responses

Jarrod

Download

Or download directly here

Additional References

Want more?

Check out the “Ask Udi” archives.

Got a question?

[Podcast] Durable Services with WCF, WF, and NServiceBus

Udi Dahan — Tue, 23 Oct 2007 21:17:40 +0000

In this podcast we’ll look at the issues around Durable Services, what makes them stateful or stateless, as well as how WCF and WF can be used to implement them. Finally, we’ll compare solutions based on .NET 3.5 and on NServiceBus–covering aspects such as transactions and persistent time-outs.

Suresh asks:

Hi Udi,

I’ve been reading about the coming “durable services” that will be available with the next version of WCF. I also have been listening to your podcasts and reading your blog posts about NServiceBus where you talk about long-running workflows. It sounds like both of these technologies are trying to solve the same problem.

Do durable services do away with long-running workflow? If so, does that mean we don’t need Workflow Foundation either? If not, what is the connection between them.

If you could shed some light on the matter that would be great.

Suresh

Download

Or download directly here

Additional References

Blog post on Workflow Services in Orcas
Blog post on Orcas Durable Services
Blog post on .NET Framework 3.5 Beta1 is Live on the Web

Want more?

Check out the “Ask Udi” archives.

Got a question?

[Podcast] Thread-Safe Asynchronous Smart Clients

Udi Dahan — Fri, 12 Oct 2007 07:08:09 +0000

In this podcast we’ll look at various patterns involved in creating MVC-based Smart Clients which communicate using asynchronous messaging and how to avoid threading problems there.

Neil asks:

Hi Udi,

We’re building a smart client application that uses WCF for full-duplex communications with our server. This is the asynchronous communication you talk about in your podcast. The smart-client is based on the MVC pattern, where model objects raise events when they’re changed so that the views can update themselves.

What’s started happening recently is that the smart-client has been freezing-up on us intermittently. We don’t know how to debug this and are wondering if its an architectural problem.

Any help you can give would be most appreciated.

Neil

Download

Or download directly here

Additional References

Blog post on Occasionally Connected Systems Architecture
Blog post on ObjectBuilder synchronization features needed for pub/sub-ing Smart Clients

Want more?

Check out the “Ask Udi” archives.

Got a question?

Download via the Dr. Dobb’s site.

[Podcast] Domain Models, SOA, and The Single Version of the Truth

Udi Dahan — Wed, 12 Sep 2007 08:56:12 +0000

In this podcast we’ll try to describe some of the pitfalls of trying to split a domain model between multiple services, as well as how SOA side-steps the “single version of the truth” issue found in reporting.

Rishi asks:

Hi Udi,
First of all, thanks for all the posts and info you share, it is very insightful compared to loads n’ loads of marketing bull and vendor whitepapers. Ok, I have two questions for you.

1. I want to create a SOA-based LOB application/platform and I generally understand the ‘tenets of services’ and reasons for the same. However, as you may well know, there is a lot of interdependency between business constructs (such as a customer with an order, or a delivery with a product construct). Now, should we share these constructs within a tightly-coupled and domain-based “system” which exposes a number of services to the outside world and use the constructs directly inside the so-called “system” boundary. Or on the opposite spectrum have a number of autonomous and independent services that expose, own, and share certain business constructs or at least part of the data that represents them as a whole. For example, an order service will need to interact with a customer construct, which primarily/essentially is (or should be?) owned by a customer profile service – in this context, with clear, direct, and immediate inter-dependency what is preferable? Where do we draw the enclosing line?

2. In a line of business application, reporting and shaping data are a given necessity. Now, with autonomous and independent services which define business constructs in their contextual ways, how do we practically shape, combine, and filter data across various services? We certainly can’t do joins over multiple services in a practical way? And as some suggest, if we are to maintain duplicate or master data elsewhere, it just seems very messy to me – just consider having 3 versions of an order services, with 2 versions of support services, and ‘n’ number of other services to comb data from. Further, for reporting and also analytical purposes we really need to have business data structured in a well-defined manner, which for all purposes needs to be the “single version of the truth”. I can’t see granular services, with all its tenets, sitting nicely with such other requirements of the business – and yet I am not even asking them to be real-time. How do we meet such business requirements in your view with SOA?

Hope the above makes sense!

Cheers,
Rishi

PS: I use the word business construct purposefully, and it does not directly attribute to a well-defined programmable entity (in object-oriented way, that is).

Or download directly here.

Additional References

Want more?

Check out the “Ask Udi” archives.

Got a question?

[Podcast] Shared subscriptions between autonomous components

Udi Dahan — Mon, 10 Sep 2007 05:30:15 +0000

This week we’re discussing scenarios involving the use of multiple autonomous components handling the same event. We also get into the topics of component hosting as well as solution development structure.

Our long-time listener Bill asks the following:

Hi Udi,

Thank you for your podcast clarifying the concept of autonomous components. It certainly cleared up a lot in terms of how you define an autonomous component and helped position the concept better in my mind.

I am considering building our Policy Administration service with 3 autonomous components as you previously suggested – one for each insurance product family. As you previously mentioned, these autonomous components could either share a database instance or have separate database instances, even though they may share schema (being a part of the same service).

What concerns me however is that there is some data that must be shared between these autonomous components. A perfect example is Region. If a new Region is defined somewhere in the enterprise, a RegionCreatedNotification is published onto the bus. If I have 3 autonomous components sharing the same database, is it best I just choose one to be the subscriber for this event? Or should I create a new separate queue to receive these notifications and put a message handler for it in a separate MessageHandlers assembly? Or should I subscribe all 3 autonomous components and have them each check if the Region has already been created in the database before inserting a new one?

Option (1) seems presumptuous because it assumes all 3 autonomous components are sharing the same database. Option (2) seems a bit strange because it is like creating a 4th autonomous component only to receive the RegionCreatedNotification messages. And Option (3) seems wasteful since there is redundant code and the system is doing extra unnecessary lookups. At the moment it looks like Option (2) is my best bet, but I’m very interested to get your take on it.

Another question is whether you would say that autonomous components should be hosted in different processes. Since I don’t need to run these autonomous components on separate servers at this stage, it would seem wasteful to create a service host for each component. I could always create separate service hosts at a later time if I needed to host one or more autonomous components on other servers.

And the final question I have is in terms of solution structure. I was contemplating the following structure:

ProductFamily1
———————-
Company.PolicyAdministration.ProductFamily1.Domain
Company.PolicyAdministration.ProductFamily1.MessageHandlers
Company.PolicyAdministration.ProductFamily1.Messages
Company.PolicyAdministration.ProductFamily1.Persistence
Company.PolicyAdministration.ProductFamily1.Persistence.Implementation
Company.PolicyAdministration.ProductFamily1.Etc…

ProductFamily2
———————-
Company.PolicyAdministration.ProductFamily2.Domain
Company.PolicyAdministration.ProductFamily2.MessageHandlers
Company.PolicyAdministration.ProductFamily2.Messages
Company.PolicyAdministration.ProductFamily2.Persistence
Company.PolicyAdministration.ProductFamily2.Persistence.Implementation
Company.PolicyAdministration.ProductFamily2.Etc…

ProductFamily3
———————-
Company.PolicyAdministration.ProductFamily3.Domain
Company.PolicyAdministration.ProductFamily3.MessageHandlers
Company.PolicyAdministration.ProductFamily3.Messages
Company.PolicyAdministration.ProductFamily3.Persistence
Company.PolicyAdministration.ProductFamily3.Persistence.Implementation
Company.PolicyAdministration.ProductFamily3.Etc…

Common
———————-
Company.PolicyAdministration.Common.Domain
Company.PolicyAdministration.Common.Persistence
Company.PolicyAdministration.Common.Messages
Company.PolicyAdministration.Common.ServiceHost
Company.PolicyAdministration.Common.Etc…

Do you have any thoughts on the above structure?

Once again thank you very much for your extremely valuable advice!

Best Regards,
Bill

Or download directly here.

Additional References:

Want More?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question and have him answer it on the show: podcast@UdiDahan.com.

[Podcast] Can We Do Away with Services and Just Leave the Messaging?

Udi Dahan — Sat, 11 Aug 2007 09:18:38 +0000

This week we have a comment from a fellow SOA blogger, Jack van Hoof:

ESB’s are a lot about messaging and therefore a better name might be “Enterprise Data Bus”. It’s the asynchronous messaging that needs such an infrastructure with persistency and mediation facilities. All the WS-* standards are about messaging as well, leveraging the message itself to tell the infrastructure how it has to be handled.

I think WS-* will make it possible to have the ESB evolve from a vendor-product to a concept implemented in the operating systems an network devices that understand WS-*. Then you can leave the prefix “Enterprise” and we will be ready for an univeral asynchronous data bus over the Internet (or any other network you like). This will help breaking the current “services centric” idea of SOA into a “messages centric” perspective.

What are your thoughts?

Or download directly here.

Additional References:

Want more? Check out the “Ask Udi” archives.

Got a question? Have Udi answer it on the podcast – podcast@UdiDahan.com

[Podcast] Interview with Paul Preiss – IASA President and Founder

Udi Dahan — Wed, 08 Aug 2007 04:47:48 +0000

In this podcast we talk to Paul Preiss, President and Founder of the International Association of Software Architects, about the field of IT Architecture, the value IASA brings to architects, vendors, and corporate IT, as well as the various training programs available including the free Skills Library–over 600 pages of articles written by architects for architects.

Ask Udi a question for the podcast…

Or download directly here.

Additional References:

How to start your own IASA chapter

Join the IASA Training Program

Want more?

Check out the “Ask Udi” archives

[Podcast] Using WCF for Entity and Activity Services to Implement Business Services

Udi Dahan — Tue, 17 Jul 2007 14:00:08 +0000

This week we return to the topic of Entity, Activity, and Process services and compares their usages as top-level SOA elements and as implementation details of the application architecture inside a business service.

And the question that this answers is:

Hi Udi,

We’ve been having some discussions about how to implement our latest project using SOA and this is what we came up with:

Every activity is a method, which is broken into a class ( Think separation of concerns ), so we get high reusability.
On top of those classes we have decided to put a WCF layer, so you can expose the method as a web method. If an activity needs data, then it will access a entity service via WCF. To make the activities useful for the business we put them in a class which we have called processes ( a process layer). A process contains one or more activities and is able to call other processes and activities aren’t allowed to call processes or other activities. On top of each process we have decided to put a WCF so the UI can access them.

So it’s pretty close to what you wrote about in the Microsoft Architecture Journal except that we don’t have direct call to the entity services, we wrap it up in an activity before the call, which is wrapped in a WCF-host. Much like the definitions in Ontology and Taxonomy of Services in a Service-Oriented Architecture

I would love to hear your comments and thoughts about this architecture.

With thanks, Ingo

Download via the Dr. Dobb’s site.

Or download directly here.

Additional References:

Want More?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question and have him answer it on the show: podcast@UdiDahan.com.

[Podcast] Passing Data Between Layers in SOA Model/Smart Client Application

Udi Dahan — Thu, 12 Jul 2007 22:37:18 +0000

This week we discuss the different options that are available for passing data between a client and a service, as well as common pitfalls around trying to use the same objects for both presentation to the user and persistence to the database.

Or download directly here.

And here’s the question that gets us started:

Hello there,

We are developing an application in .NET Smart Client application which connects to a WCF service and then to the data access layer. The issue we have here is on the type of data which can be passed between the client side and web service.

1. Can it be a dataset (No!), custom entity or XML or anything else ?

Which is the best one ?

2. Ofcourse , a dataset can’t be used coz it can’t be used in non-.NET environment?

3. If we go for custom-entity or XML how do we ensure the changes happen to the data during client-side actions ? For example, binding the XML or custom entity to a data grid can be done. But if user makes any changes to the same, how do we identify ?

4. If we use custom entities / XM L, the same can not be passed to the Data Access Application Block which invokes the data objects.

Note : All the above are based on assumption without using a translator in between any of the layers.

Please provide a better solution if you have come across any.

Additional References:

Podcast on using DataSets with Web Services

[Podcast] Ross Mason on ESBs and the Mule Project

Udi Dahan — Sat, 30 Jun 2007 14:03:26 +0000

In this podcast we talk to Ross Mason about the value Enterprise Service Buses (ESBs) provide over regular Enterprise Application Integration products and how Mule, a Java-based open-source ESB, makes ESBs easy to use.

Download via the Dr. Dobb’s site.

Or download directly here.

Additional References:

[Podcast] Sockets, Web Services, and Security

Udi Dahan — Thu, 21 Jun 2007 20:00:47 +0000

In this podcast we answer questions about the considerations of choosing various communications technology–from TCP and UDP sockets, to .NET Remoting, Web Services, and Windows Communication Foundation. Also, issues such as scalability and security are discussed in the context of company intranets.

Or download directly here.

Here’s the original question:

Hi Udi,

This is Kumar, i am new to .NET and related technologies. Actually i am designing an application with few a components like a Socket Server(a service) which received input from payment terminal for loyalty application, which should communicate with Web Services deployed in an IIS application server, then the web services should communicate with an Oracle Database.

What are the patterns and best practices to use for the communication between the socket server and application server, and how do I scale for multiple clients in socketserver, and what are the security things that i need to consider.

Should i need to use .NET Remoting instead Web Services for my application server layer, and which is best for my socket server?

Thank you for your support.

Kumar

Additional References

[Podcast] Asynch Communication and the User Experience

Udi Dahan — Thu, 21 Jun 2007 19:40:29 +0000

In this podcast we answer questions about how web presentation layers can communicate asynchronously with services, Service Level Agreements with respect to asynchronous user interaction, and if using compiled DLLs for message schemas creates tight coupling.

Download via the Dr. Dobbs’ site

Or download directly here.

And here’s the original question:

Hi Udi,

I thought I’d ask a question about an implementation that seems to be bouncing off my head. We have been thinking about services that can, at the business owners discretion based on SLA expectations, be synchronous, async but within a “human” timeframe ie, the gui could still wait and just fail gracefully if the response took too long, or async where the client must check back later.

Client abc is using application xyz and sends a message via the bus to do something. Logically, client abc is waiting for a response even though application xyz sent it asynchronously. Client abc may wait with the gui in front of them, with a progress bar running or a little ajaxy polling widget. They may wait for an email or an message on their web site for long running operations. How would you arrange that the response to this particular message would get routed to only client abc? If the answer is you shouldn’t think that way, then what would a subscriber to that message type, as shown in your example, do with the client abc’s response? Imagine a password reset example where the result is a temporary password but the service consults or updates multiple systems as a result of the request.

You also use a shared message type library. As we have been studying WCF, we have focused mostly on the features that would help us allow service consumers and suppliers move independently. We have been looking at message versioning and loose coupling techniques. We have settled on the idea that a shared message library would make our message too brittle, once again forcing each consumer to sync up with each service update. What is your take on that?

Philip

Additional Resources

[Podcast] Using Autonomous Components for SLAs in SOA

Udi Dahan — Sun, 03 Jun 2007 05:07:36 +0000

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.

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

[Podcast] Handling Dependencies Between Subscribers in SOA

Udi Dahan — Thu, 31 May 2007 20:59:28 +0000

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.