Comments on: I Hate WSDL http://www.udidahan.com/2008/03/28/i-hate-wsdl/ Enterprise Development Expert & SOA Specialist Thu, 09 Sep 2010 15:41:11 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: udidahan http://www.udidahan.com/2008/03/28/i-hate-wsdl/comment-page-1/#comment-19973 udidahan Wed, 02 Apr 2008 20:52:02 +0000 http://udidahan.weblogs.us/2008/03/28/i-hate-wsdl/#comment-19973 Joel, You can always try to call it "one-way messaging" as opposed to "asynchronous messaging" :) I've already mentioned before that users/operators care how fast the response comes - not how it comes, so that's not an issue. Rather, when using one-way messaging, we often get better throughput resulting in fast response times overall, so it's actually better for users. In terms of complexity, I think that the whole solution needs to be examined. What I mean by that is that it is simpler to solve problems like robustness using one-way messaging than with RPC. You also often get a more flexible solution (one request/multiple responses) that often decreases the complexity of the solution (one gigantic response structure with bit fields saying what it means). It looks like you want to go in the right direction - don't give up :) Joel,

You can always try to call it “one-way messaging” as opposed to “asynchronous messaging” :)

I’ve already mentioned before that users/operators care how fast the response comes – not how it comes, so that’s not an issue. Rather, when using one-way messaging, we often get better throughput resulting in fast response times overall, so it’s actually better for users.

In terms of complexity, I think that the whole solution needs to be examined. What I mean by that is that it is simpler to solve problems like robustness using one-way messaging than with RPC. You also often get a more flexible solution (one request/multiple responses) that often decreases the complexity of the solution (one gigantic response structure with bit fields saying what it means).

It looks like you want to go in the right direction – don’t give up :)

]]> By: Joel http://www.udidahan.com/2008/03/28/i-hate-wsdl/comment-page-1/#comment-19966 Joel Wed, 02 Apr 2008 18:09:32 +0000 http://udidahan.weblogs.us/2008/03/28/i-hate-wsdl/#comment-19966 I have been trying to move our architecture over to an asynchronous messaging based solution for quite a while now. Unfortunately, people hear the term "asynchronous" and immediately start bringing up performance or complexity concerns. The most common concerns I hear are that the solution needs to be "real-time" because an operator is waiting for the response and that the client will need to implement a correlation mechanism. They immediately assume that because someone is sitting there waiting the whole solution needs to be synchronous, which is, obviously, an incorrect assumption. Even reliability concerns can be addressed by asynchronous messaging. I've always argued that I would rather build reliability into the workflow logic/business process than have to rely on some potentially complex reliability mechanism like ebMS or WS-RM. Why is it such a crime to have a process wait for an asynchronous response that is correlated to the request? If a response isn't received in x amount of time, resend or perform some other form of recovery. Doing this allows you much more flexibility, in workflow and choice of transports, and probably increases overall interoperability because you don't have to worry whether a partner's environment of choice supports a specific reliability mechanism. I keep telling myself that I need to set aside some time to look at nServiceBus but managing BizTalk's complexity is becoming a full-time job. I have been trying to move our architecture over to an asynchronous messaging based solution for quite a while now. Unfortunately, people hear the term “asynchronous” and immediately start bringing up performance or complexity concerns. The most common concerns I hear are that the solution needs to be “real-time” because an operator is waiting for the response and that the client will need to implement a correlation mechanism. They immediately assume that because someone is sitting there waiting the whole solution needs to be synchronous, which is, obviously, an incorrect assumption.

Even reliability concerns can be addressed by asynchronous messaging. I’ve always argued that I would rather build reliability into the workflow logic/business process than have to rely on some potentially complex reliability mechanism like ebMS or WS-RM. Why is it such a crime to have a process wait for an asynchronous response that is correlated to the request? If a response isn’t received in x amount of time, resend or perform some other form of recovery. Doing this allows you much more flexibility, in workflow and choice of transports, and probably increases overall interoperability because you don’t have to worry whether a partner’s environment of choice supports a specific reliability mechanism.

I keep telling myself that I need to set aside some time to look at nServiceBus but managing BizTalk’s complexity is becoming a full-time job.

]]>