SOA Design - Polling or Push

I'm sitting on the fence on this one, and wanted to get some other people's
input. If you're a big B2B person, I would love to hear your feedback...

I've got a SOA system. It's based on a combination of WCF Services and
ASP.Net Pages. The consumers of this service are companies all over North
America.

Essentially, we've got some long running operations that a vendor can kick
off. These opertaions can take anwhere from 5 minutes to 2 weeks (with the
average being "a few days").

On the WCF side of things, I've got everything designed out. I've got clean
Request/Response Messages, Faults, Contracts, and everything all completed
and ready to go. All the common best practices for Versioning, Interface
Design, and Security have been (I think!) followed.

Load on this system is low. A few hundred, maybe a few thousand requests per
day.

I'm on the fence though with Status Checks. As it sits, I've two options:

*** Option 1 ***
Require vendors to poll our services on a regular basis checking for status.
The poll interval would probably be between 5 minutes and 60 minutes.
Polling would be done via a call on the WCF service.

Pros:
- No exteneral dependencies for us. This means we have to only worry about
our own infrastructure.
- No requirements for vendors to setup and manage servers that we contact
with a push of some sort.

Cons:
- It's polling, and everything I know says polling is bad. I'm using to
building super scalable systems in terms of transaction volume, and this
system is nothing like that, so polling may be alright.

*** Option 2 ***
Require vendor to send us a URL that we touch upon completion of the
process. This could also be a WCF call, but I think most vendors are more
able to setup the URL than a Secure Service. Our vendors are, for the most
part, not highly technical companies.

Pros:
- No polling. Vendors know exactly when a request has completed.

Cons:
- Vendor needs to setup and manage a highly available service.
- Vendor needs to build a "Unique URL" or some similar system, that we can
post into.
- Signifigant flow issues if their service is down, and we need to do
retries.
- We are now dependant upon their system, and there could be SLA
implications.

I'm leaning towards the Polling option, but hopefully someone here has some
experience in this area...

--
Chris Mullins

Re: SOA Design - Polling or Push

Hi, Chris

Just some ideas to consider:

1. Support both methods, this gives the clients more options.
2. Maybe you can provide some kind of canned response service that they can
configure and setup with just a little work or with your help, you could
even provide the entire system ready to go [shipped to them].

Good luck

Eric Schneider


"Chris Mullins [MVP - C#]" wrote in message
news:eafB8URDIHA.5328@TK2MSFTNGP05.phx.gbl...
> I'm sitting on the fence on this one, and wanted to get some other
> people's input. If you're a big B2B person, I would love to hear your
> feedback...
>
> I've got a SOA system. It's based on a combination of WCF Services and
> ASP.Net Pages. The consumers of this service are companies all over North
> America.
>
> Essentially, we've got some long running operations that a vendor can kick
> off. These opertaions can take anwhere from 5 minutes to 2 weeks (with the
> average being "a few days").
>
> On the WCF side of things, I've got everything designed out. I've got
> clean Request/Response Messages, Faults, Contracts, and everything all
> completed and ready to go. All the common best practices for Versioning,
> Interface Design, and Security have been (I think!) followed.
>
> Load on this system is low. A few hundred, maybe a few thousand requests
> per day.
>
> I'm on the fence though with Status Checks. As it sits, I've two options:
>
> *** Option 1 ***
> Require vendors to poll our services on a regular basis checking for
> status. The poll interval would probably be between 5 minutes and 60
> minutes. Polling would be done via a call on the WCF service.
>
> Pros:
> - No exteneral dependencies for us. This means we have to only worry about
> our own infrastructure.
> - No requirements for vendors to setup and manage servers that we contact
> with a push of some sort.
>
> Cons:
> - It's polling, and everything I know says polling is bad. I'm using to
> building super scalable systems in terms of transaction volume, and this
> system is nothing like that, so polling may be alright.
>
> *** Option 2 ***
> Require vendor to send us a URL that we touch upon completion of the
> process. This could also be a WCF call, but I think most vendors are more
> able to setup the URL than a Secure Service. Our vendors are, for the most
> part, not highly technical companies.
>
> Pros:
> - No polling. Vendors know exactly when a request has completed.
>
> Cons:
> - Vendor needs to setup and manage a highly available service.
> - Vendor needs to build a "Unique URL" or some similar system, that we can
> post into.
> - Signifigant flow issues if their service is down, and we need to do
> retries.
> - We are now dependant upon their system, and there could be SLA
> implications.
>
> I'm leaning towards the Polling option, but hopefully someone here has
> some experience in this area...
>
> --
> Chris Mullins
>

RE: SOA Design - Polling or Push

I would certainly privide option 1. It would be useful to both customers and
your organization. Perhaps something like what UPS provides for tracking a
shipment.

Some customers may use the service infrequently, and an email notification
might be a good idea for them (a variant of option 2).

"Chris Mullins [MVP - C#]" wrote:

> I'm sitting on the fence on this one, and wanted to get some other people's
> input. If you're a big B2B person, I would love to hear your feedback...
>
> I've got a SOA system. It's based on a combination of WCF Services and
> ASP.Net Pages. The consumers of this service are companies all over North
> America.
>
> Essentially, we've got some long running operations that a vendor can kick
> off. These opertaions can take anwhere from 5 minutes to 2 weeks (with the
> average being "a few days").
>
> On the WCF side of things, I've got everything designed out. I've got clean
> Request/Response Messages, Faults, Contracts, and everything all completed
> and ready to go. All the common best practices for Versioning, Interface
> Design, and Security have been (I think!) followed.
>
> Load on this system is low. A few hundred, maybe a few thousand requests per
> day.
>
> I'm on the fence though with Status Checks. As it sits, I've two options:
>
> *** Option 1 ***
> Require vendors to poll our services on a regular basis checking for status.
> The poll interval would probably be between 5 minutes and 60 minutes.
> Polling would be done via a call on the WCF service.
>
> Pros:
> - No exteneral dependencies for us. This means we have to only worry about
> our own infrastructure.
> - No requirements for vendors to setup and manage servers that we contact
> with a push of some sort.
>
> Cons:
> - It's polling, and everything I know says polling is bad. I'm using to
> building super scalable systems in terms of transaction volume, and this
> system is nothing like that, so polling may be alright.
>
> *** Option 2 ***
> Require vendor to send us a URL that we touch upon completion of the
> process. This could also be a WCF call, but I think most vendors are more
> able to setup the URL than a Secure Service. Our vendors are, for the most
> part, not highly technical companies.
>
> Pros:
> - No polling. Vendors know exactly when a request has completed.
>
> Cons:
> - Vendor needs to setup and manage a highly available service.
> - Vendor needs to build a "Unique URL" or some similar system, that we can
> post into.
> - Signifigant flow issues if their service is down, and we need to do
> retries.
> - We are now dependant upon their system, and there could be SLA
> implications.
>
> I'm leaning towards the Polling option, but hopefully someone here has some
> experience in this area...
>
> --
> Chris Mullins
>
>
>

Re: SOA Design - Polling or Push

On Fri, 12 Oct 2007 14:17:52 -0700, "Chris Mullins [MVP - C#]"
wrote:

>I'm sitting on the fence on this one, and wanted to get some other people's
>input. If you're a big B2B person, I would love to hear your feedback...
-snip-
I'm doing something similar passing selections from a browser-based
catalog to various desktop applications. This sort of IPC is very
difficult to automate unless the client uses an embedded browser. My
client could have chosen a better tool.
>
>I'm on the fence though with Status Checks. As it sits, I've two options:
>
>*** Option 1 ***
>Require vendors to poll our services on a regular basis checking for status.
>The poll interval would probably be between 5 minutes and 60 minutes.
>Polling would be done via a call on the WCF service.
>
- snip -
>
>*** Option 2 ***
>Require vendor to send us a URL that we touch upon completion of the
>process. This could also be a WCF call, but I think most vendors are more
>able to setup the URL than a Secure Service. Our vendors are, for the most
>part, not highly technical companies.
>
- snip -
>
>I'm leaning towards the Polling option, but hopefully someone here has some
>experience in this area...

I am leery of polling because of previous experiences with ill-behaved
client applications. I assume 'touch' means notifying the client the
process is complete. Then the client makes a request to a service for
the results. If that is the case, touch the client.

regards
A.G.