New SOA Book Next Year called PRO WCF: Practical Microsoft SOA Implementation

Beginning of the new year a new book concerning SOA and Microsoft will be released through Apress. It is called PRO WCF: Practical Microsoft SOA Implementation.

It is written by a number of professionals like Amit Bahree, Chris Peiris, Aftab Chopra, Shawn Cicoria, Nishith Pathak and Dennis Mulder. Last one is a dutch guy I met during SOA & BPM conference at Microsoft in Redmond. He’s a very nice guy and I had a couple of chats with him during the conference. He also mentioned he was working on this book. So it cool to know one of the authors, but I am also very interested in its content.


So what’s the book about:

Part of Microsoft’s radical new WinFX API is the Indigo foundation, more formally known as the Windows Communication Foundation, or WCF. Pro WCF: Practical Microsoft SOA Implementation is a complete guide to WCF from the SOA architecture perspective and shows you why WCF is important to web service development and architecture.

The book covers the unified programming model, reliable messaging, security, the peer-to-peer programming model, and more. You’ll also learn how to move your current DCOM and .NET remoting applications to WCF, and how to integrate those applications with new WCF-based applications.

You’ll want to get ahold of a copy because it
* Contains a comprehensive WCF programming model
* Explains how queue management and reliable messaging work in WCF
* Discusses implementing transaction support in WCF
* Shows how to make WCF services interoperable with other SOA offerings
* Thoroughly covers WCF security topics and concerns

Source (http://www.apress.com/book/bookDisplay.html?bID=10185)

Today I bought the beta version of the book, so when I have some spare time left I will be reading the chapters I have downloaded so far.

Content Based Routing: EAI Challenge, what's the best solution Part II

In a previous post I mention an scenario, where Content Based Routing is involved. I asked a couple of people in the BizTalk space around the world about their opinion. Here are some more:

Jon Flanders -

Hi Steef – you could do this with your own database and a dynamic port. Or you could use a ROleLink and use the TPM functionality (BAS) to allow your customer to maintain and add partners.

It certainly is a form of the CBR pattern no matter which implementation you use.

Lex Hegt -

Hi Steef-Jan,

At a conceptual level CBR exists as a design pattern which can be implemented with several message brokers. BizTalk 2006 (and 2004 as well) is one of those brokers, so if you should choose for CBR and your customer already has BTS 2006, they won't need another product.

The solution you choose depends (amongst others) on how fast the data needs to available at the target system. The advantage of CBR is that (off course) you don't need an orchestration. So at run-time no instance needs to be created and no data needs to be persisted along the way, giving you a better performance than a solution with an orchestration. So far small packages of data which need to be delivered quickly, CBR should do the job fine. Where needed, you can use SSO for authentication and when the same data must be send to several parties, you can use a Send Port Group, to keep routing simple. The latter works from an orchestration as well off course.
Another disadvantage when using an orchestration is that although you can create dynamic ports, the 'dynamic' part is sender-related, not protocol-related. So, depending on the protocol of the target system you will need multiple logical ports in your orchestration, which will be bound to multiple physical protocol ports. This leaves you with a more complex solution than you probably would be necessary.

Resuming: I would use CBR for your solution. Page 256 of the book you mentioned, contains a list of when (not) to choose for a solution with an orchestration.

Hope this helps. Feel free to come back!

I must say that I am very happy with the responses so far and looking forward to some more.

New Challenges for me

I am currently involved in a project bringing a complete suite of payroll and human resource applications in one ASP framework. A Payroll/HR player in Holland wants to centralize all their apps and provide software as a service (also known as SaaS). Their ASP model consists of an authentication/authorization layer, where probably BMC® Identity Management for .Net is going to be used.










More about the product can be found here.

Second layer will be a visual integration layer (presentation), so customers get an integrated feeling when they use their applications instead of opening all applications separately. This layer will be build completly with ASP.NET 2.0. Third Layer will be all the applications hooked with the second layer and this is the interesting part. .Net Technology is used throughout this organization and they want to develop interfaces between third and second layer using Windows Communication Foundation. So an interesting challenge using .NET in all layers together with third party software (BMC) and custom build software (.NET, other development languages like java and so on).

More about netfx3.0 can be found here here .

Content Based Routing: EAI Challenge, what's the best solution

Recently I was confronted with the following scenario, where I asked the authors of BizTalk Pro for advise:

I am a Microsoft BizTalk Consultant in the Netherlands and I would like to ask you a question about Content-based Routing. The question is does Content Based Routing (CBR) exists inside BizTalk Server 2006 as functionality by itself of is it a design pattern, practice as you wrote in your book (Chapter 6 BizTalk Design Patterns and Practices page 198). The reason I am asking this, because a customer we are doing a BizTalk implementation is wondering if a CBR could be a solution to their specific problem and if this is standard functionality in BizTalk or do they need another solution. Problem they are having is that their flex worker ERP systems exports different kinds of flat-file and xml files (between 20k and 20 Mb large) for the Dutch tax department, bank and so on (3rd parties). Flat files contain a header with metadata what kind of file it is and where it is originated inside the system. The XML files are exported with same metadata in an envelope. These files are send to 3rd parties using FTP, SMTP or SOAP protocol. All these protocols and maybe other protocols in the future need to be supported. We suggested a orchestration with one receive location (folder) to pick up any kind of exported file (flat or xml) and based on its metadata a lookup is done in a database table to find address data and other data like authentication data so a dynamic port is created and the file is send by FTP, HTTP and SMTP or all if necessary. This could also be done using BRE instead of using a database lookup. What we want to achieve through this solution was that with the Meta data any kind of address the customer want can be placed inside a database and the BizTalk application (orchestration) could be left untouched. What would you suggest this solution of CBR?

George Dunphy answered:

Hi Steef,CBR is a feature of BizTalk. This is something that comes with the product when you purchase it. The situation you describe seems like a classic example of where you would use CBR. Chapter 3 we discuss this as well. CBR should be able to parse your document and route it to the appropriate destiantion based on what properties are promoted.Hope that helps.

I also asked some other experts in BizTalk field like Stephen W Thomas, Tomas Restrepo and Richard Seroter. Tomas replied this:

Technically speaking, it is definitely possible to do this using CBR. What you’d need to do is create a property schema and promote the relevant field in the message schema to a property in your property schema, thus making it available for routing. Once that is done, you could just create your send ports and add Filter expressions built on your custom promoted property to enable the routing scenarios.

So definitely this is possible, and in some cases it is far more efficient because all the work is done by the biztalk Pub/Sub engine. That said, there are tradeoffs. Depending on your scenario, using pure CBR might be more complex to manage (all the configuration work/changes needs to be done by the biztalk administrator), and in some scenarios it might be more complex to debug/tracking because any configuration error (or missing configuration) would generate a routing failure, compared to your custom orchestration/db which could implement more advanced error handling/retry mechanisms.

And also Richard Seroter replied:

Your solution description below is perfectly viable. That is, accept data in via any format, use metadata to determine routing. As you said, you could do a straight database lookup in a pipeline, map or orchestration, or, you could use the BRE.Making sure that you could add new lookups without modifying the orchestration (or ANY deployed component) would be key in making this purely content based routing. That said, you'd still have the flexibility to add an orchestration that only subscribes to specific data elements.

Well from these answers I can tell that to my scenario that strictly CBR, without an orchestration but simple filter options is not the best option, besiedes that the customer is looking for routing using different protocols, it also wants logging, errorhandling and audit trail.

I must say that reading the BizTalk Pro book really gave some more understanding of BizTalk. This book and the recipes from APRESS are the best on BizTalk 2006 so far.

Here are the book details:

By George DunphyAhmed Metwally
ISBN: 1-59059-699-4
528 pp.
Published: Oct 2006