This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes part II - payment transaction query Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "part II - payment transaction query" Watch "part II - payment transaction query" New topic
Author

part II - payment transaction query

Peter Warde
Ranch Hand

Joined: Aug 18, 2004
Posts: 71
If you have reservation process that includes a payment transaction involving processing a credit card by accessing another system using XML-RPC over HTTPS or looking up customer details on another system using HTTPS, and you want the process to be all within a single transaction so that if the process fails at some point the payment transaction on the other system rolls back etc, how can you guarantuee this?

Or do you just assume that the other systems support transactions propagated from you to them with the HTTPS protocol?

Any one has any thoughts?

Thanks

Peter
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Hi Peter,

I would go with your second choice - assumptions

Regards,
Dan


William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Ricardo Ferreira
Ranch Hand

Joined: Feb 13, 2006
Posts: 156
Peter,

Normally, your scenario is very common for any web distributed application, and the most common approach is, let the subsystem manage the transaction to you, and provide only an code the signals the transaction.

For example, your application could call an web service to process a credit card shopping, and if the web service call return 102 code, means that the credit card processing has been failed. Your application based on this code should rollback any operations that could be done.

But, there is some cases the an transactions must be started by one application and propagated for others web services. To meet this requirement, you must use some SOA infrastrcture like ESB (Enterprise Service Bus) that take care of this transaction propagation.

The ESB service do this creating a common tunnel that every incomming and outcomming web services must pass by it. And an transaction could be remaining during some business service execution.

But honestly, at the most cases, the called web service takes care of the processing transaction and signals are shared among the business processes. SOA and ESB is a emerging industry technology that do not have many cases using this approach. But this story tends to change as Gartner has said a few months ago

Best Regards,


Ricardo Ferreira,<br /> <br />Sun Certified Enterprise Architect<br />IBM Certified SOA Solution Designer<br />IBM Certified RUP v7.0 Solution Designer<br />IBM Certified Specialist for RUP v2003
Andy Malakov
Greenhorn

Joined: Aug 30, 2006
Posts: 26
We can theoretically assume that Transmaster supports WS-Transaction, but it seems that Perl-based Frequent Flyer system does not offer any transactional API.

JCA Adapters for both?
Andrew Zilahi
Ranch Hand

Joined: Oct 16, 2006
Posts: 47
Perform only 1 payment at a time. FBN system records all aspects of the transaction less a flag (isPaid or something), then issues transmaster request. If transmaster call fails, error log is being generated and isPaid = false.
What do you think?

Andrew


--------------------------<br />SCJP,SCJD,IBM XML, SCEA 1
Steve Taiwan
Ranch Hand

Joined: Jul 01, 2003
Posts: 166
I think in most cases XA transaction is not possible, especially when it invovles external sources or legacy system.
Regarding WS-Transaction, I don't expect TransMaster provide it to FBN.
So I will split the transaction to 3 parts.
1. Make an order, persit it to database.
2. call TransMaster
3. Get returned code from TransMaster, do post process, persist the code to the related order.

If step 1 fails, skip step 2 and 3.
If step 2 fails, some internal process will redo it automatically or a alert will be sent with other manual process.
If step 3 fails, redo step 2 and let customer service handle double charge and customer complaim.

What do you thank?


Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: part II - payment transaction query
 
Similar Threads
E-commerce (Credit Card Processing)
XML-RPC over HTTPS requirement for both web and Swing client for Payment
about Pay for Itinerary
Question about Part 2 assignment.
Payment Gateway - dual verification check