While writing my thoughts about SOAP being a first-tier technology, I hoped that someone would catch up on it and think through my ERP example. People did this and responded to me by email: What if the customer wants to be notified as soon as the order is fulfilled? What if the manufacturer wants to notify the vendor or shipper that the order isn't ready to be picked up on the planned date? Isn't this something that calls for callbacks?

Maybe, but do we really need protocol-based callbacks for this? I guess not, but let me state my reasons for believing this:

The supply-chain management examples from above describe two new business cases: 

• Notify the customer that his order is about to be sent
• Notify vendor and shipper that this order is delayed from the originally planned date

The handling of these would really be possible with SOAP callbacks - that is, if there were a thing like this.

But what happens if or when your customer's VIPs call your staff from their mobile phone while travelling through the country? My co-CEO does this all the time: He spends a lot of time on the road and to do something reasonable with this time, he calls the various vendors to talk about some issues and maybe places some orders as well.

In this case, the vendor wouldn't get the callback-pointer to which they should send their SOAP messages when the orders are about to be fulfilled.

So, the point is: using callbacks to map business processes to a procotol will trash your supply chain as soon as you accept orders by out-of-band channels like a phone or email. Oh, this isn't a problem for you as you don't accept orders by phone anymore because all your customers already switched to placing them via Web Services? Thought so ...

So, I guess that Web Services will just be yet another means of triggering a business process but you will still have to support all your other channels like fax, phone or email.

So, let's look again at the "notify customers of order fulfillment"-business process. How can this one be designed? I guess it goes something like this: check our database for the chosen means of notification for this customer and do whatever is appropriate: send and email, send a fax, ...

Every time I talk about business processes I somehow start to sound like those three-letter-company consultants who don't care too much about the implementation, so I better go back to technology again:

You have this ERP application which allows your staff to enter an order and you now implemented an additional SOAP endpoint so that your customers can place orders automatically. In any case, you will want to send a confirmation back to your customer as soon as the orders is about to be shipped.

You will quite certainly also have a database which specifies how your customer wants to be contacted. This however is a second-tier decision which has nothing to do with either the GUI or the SOAP endpoint in the first tier. No matter how the order enters yours system, the way of contacting your customer should be the same. At the end of the day, this means that you will have the customer's email address, fax number, etc. in your database. As you also allow notification by SOAP web services, guess where the SOAP endpoint address for the customer should go ...

So, once again, do we really need protocol-supported callbacks to make Web Service based business processes a reality? I still guess not. Quite the other way round, they will probably make things worse.

Will we need callbacks for LAN-based applications? Yes, I guess so - but this isn't a problem because you will be using a real distributed application protocol like .NET Remoting, DCOM (and COM+), RMI (and EJBs) or CORBA for these parts of your apps.