SOA Design - Polling or Push

[Chris Mullins [MVP - C#]]

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

[schneider]

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#]" <cm******@yahoo.comwrote in message
news:ea**************@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

[=?Utf-8?B?QU1lcmNlcg==?=]

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

[Registered User]

On Fri, 12 Oct 2007 14:17:52 -0700, "Chris Mullins [MVP - C#]"
<cm******@yahoo.comwrote:

>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.