THE SOFTWARE SIMPLIST

Web Services Wisdom.

December 2007

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:

• Podcast on if you need an ESB for SOA


• Podcast on Enterprise Service Discovery


• Blog post on ESBs as a global dataspace


• Blog post about what the brave new world of WS-* brings us

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

Posted by Udi Dahan at 08:27 AM  Permalink |

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.

Go to the podcast page on the Dr. Dobb's site

Or download directly here.

Additional References:

• IASA home page


• IASA Skills Library


• How to start your own IASA chapter


• Join the IASA Training Program

Check out the “Ask Udi” archives

Ask Udi a question for the podcast...

Posted by Udi Dahan at 05:05 PM  Permalink |

This week we return to the topic of Entity, Activity, and Process services and compare 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. Dobbs' site.

Or download directly here.

Additional References:

• Ontology and Taxonomy of Services in a Service-Oriented Architecture
• Udi's Architecture Journal article on Autonomous Services
• Podcast on how to structure .NET solutions and components
• Blog post covering a discussion on Entity Services

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.

Posted by Udi Dahan at 02:08 AM  Permalink |