Comments on: Can Indigo be my bus?

By: » Testing services the hard way with WCF

» Testing services the hard way with WCF — Thu, 17 May 2007 11:50:28 +0000

[...] using this message-based design, your service implementations tend to look like [...]

By: » Service-Enabled Workflows with WF and WCF

» Service-Enabled Workflows with WF and WCF — Sat, 12 May 2007 15:05:10 +0000

[...] I’ve looked over the example Guy put up in his blog on how to interact with external services from a workflow, and tried it out using asynchronous APIs with WCF. This is done quite simply by having our service accept an object as a parameter that it can call methods on (which has availability issues, but whatever). The object that we pass in is quite simply a reference to our own service. Anyway, I haven’t been able to get the SendActivity in WF to work with it. Bummer. I guess I’m “stuck” doing things the “old fashioned” way. [...]

By: » Multi-core CPU utilization with the Bus API

» Multi-core CPU utilization with the Bus API — Fri, 11 May 2007 22:59:53 +0000

[...] I base my designs around the Bus API, all my logic is both thread and process neutral. The implementation of the bus could be such that [...]

By: Udi Dahan - The Software Simplist

Udi Dahan - The Software Simplist — Sat, 03 Jun 2006 03:58:14 +0000

John,

One kind of message flow I often use between a client and an autonomous service would be similar to this (if we assum reliable messaging):

client: SubmitNewOrderMessage
service: saves orer details, kicks off long running workflow, and sends back the SubmitNewOrderMessage with a bit of metadata, OrderReceived. As the workflow progresses, more messages are sent.

In the example you give about warehouses, I definitely don’t see each warehouse as a service. The autonomous service may be your OrderFulfillmentService. Internally, it could communicate with all the different warehouses, find out which is the best candidate for fulfillment according to some complex rules, and eventually passing on the message to that warehouse. There are so many ways to handle communications within a service that spans multiple machines and domains, a bus might not be best suited. But, the boundary is important here – that’s how you know where the bus goes.

By: John Wood

John Wood — Sat, 03 Jun 2006 00:57:37 +0000

I do agree that Indigo is, like most Microsoft technologies, a bit too general purpose and makes many simple operations a whole lot more complex as a result.

I have a few questions about some points you make though.

Firstly, would you mind furnishing us with a concrete example of your message flow pattern, in a realworld application. An order system for example.

>> An autonomous service “published” that schema <<
I’m not sure I agree with that statement. Many of my services *share* schema. If I have an order form that sends an order message, there could be many different services that handle that message – different warehouses for example. I would probably have an order router service that makes that determination based on the content of the order, but the schema of the order is probably the same going into the order router as it would be going into any of the other order handling services. I personally do wire up the destination of the messages in config, but it’s still explicit for every message sender.