Hi Roger,

My application is pretty much an integration one. Today, our customer has a
lot of business application which in turn use some payment transactions with
different payment methods such as credit card (visa and mastercard), cash,
checks, deposits, etc. some of this payment services/business applications
are built in house, some are purchased, some others are hosted externally
and are implemented in different techonological platforms (say web services,
flat files, SQL Server databases, etc.).

Business applications have some logic to handle those payment requests, in a
very thigtly couple approach with all its the inherent issues of
maintenance, consistency, etc.

Our main goal is to centralize all that logic in a Payment Hub Service in
such a way that business applications inside the company just have a single
point to access all the payment request despite the method used; our second
goal is to allow to include some other payment provider by means of
configuration rather than programming. This is when all the messaging
strategy comes in; we have to deal with scenarios in which some payment
service is down, when some payment service is too slow to respond but some
"working" response should be returned to the caller, resilient messaging,
retries, handle duplicate messages, queing the requests to a payment service
since it is in maintenance, etc.; we found SQL Service Broker a good way to
implement those features.

We are considering using COM+ server applications just as facades to the
actual payment subsystem because it will allow us an out of process hosting
as well as distributed transaction consistency, since such subsystem are
mainly existing applications with their own repository.

Regards,

Ramiro

Hi Roger,

I greatly appreciate your interest.

Our application is pretty much an Application-To-Application integration one
in a SOA approach. At this moment, our customer has serveral line of
business applications which generate payment transactions with different
payment methods such as credit card (visa/mastercard), cash, checks,
deposits, etc.

Some of this payment services/business applications are built in-house, some
are purchased, some others are hosted externally (i.e. visa and mastercard)
and expose different ways to communicate each other (say web services, flat
files, SQL Server databases, etc.) and had been implemented using different
tools (.NET 1.1, Visual Basic 6.0, etc.)

Each business application has code to communicate with each payment method,
in a very tightly couple approach with all its the inherent issues of
maintenance, consistency, etc.

Our main goal is to centralize all that logic in a Payment Hub Service in
such a way that business applications inside the company just have a single
point to access all the payment request despite the method used; our second
goal is to allow to include some other payment provider by means of
configuration/metadata rather than programming. This is when all the
messaging strategy comes in; we have to deal with scenarios such as:
1. some payment  service is down
2. some payment service is too slow to respond but some "working on your
request" response should be returned to the caller to avoid undesired
timeout errors in the business application
3. resilient messaging
4. retries
5. handle duplicate messages
6. queuing the requests to a payment service due to maintenances activities,
etc.;

We found SQL Service Broker a useful to implement those features instead of
do them by hand in two scenarios:
1. Between the business applications and the payment hub service
2. Between the payment hub service and the payment sub-system.

We are considering using COM+ server applications just as facades to the
payment subsystems because that will allow us an out of process hosting
(even in different servers with DCOM), object pooling, and distributed
transaction support, since such subsystems are mainly existing applications
with their own repository.

Regards,

Ramiro