Thoughts on passing HttpRequest and HttpResponse to service layer?

I have a CommerceService module to help with common order processing functionality, which includes things like payment authorization through providers like Authorize.net, Paypal, and Google Checkout. It provides a simple interface such as placeOrder(Order) and does the heavy lifting.

Things are straight forward with local payment providers, however Paypal and Google offer remote payment services, so with Paypal for example, the user can leave your site, pay there, and Paypal will send an Http notification to hook into your order process.

The question I have is handling these notifications. Ideally it would be easiest to just pass the HttpRequest object to the service layer and let the service fulfill the order with a handleRemoteOrder(Request, Response), rather than force the front end to worry about any of this. But it seems intuitively wrong to be passing the request and response to the service layer.

I thought about extracting the request parameters to a Map and simply passing that but the google checkout java sdk works explicitly on the request and response objects, so it would be a hassle to not utilize the sdk over this concern.

Is it frowned upon to pass the HttpRequ开发者_运维问答est so far back? And if so, should there be front end logic to handle this? Or is this an unfounded worry and I shouldn't be thinking so much?

Wrap the HttpRequest and HttpResponse in your classes implementing interfaces and make the service layer rely on the interfaces. For other services than Google you can pass the map with request parameters and for the Google a wrapper implementation. Anyway, service layer wont be aware what's behind.

HttpServletRequest should not be passed to the service layer.

If you need the request explicitly you can place the logic in the web layer. Or extend the library and allow it to take a Map of parameters (if possible)

There is no reason why you can't span your Commerce Module across several layers. Treat it as what e.g. UML calls a subsystem. So that your CommerceSBS contains several components, e.g:

1. CommerceRequestMgr; controls a conversation with a PSP (generates links to PSP and callback links)
2. CommerceCallback; maybe a listener servlet awaiting the PSP callback
3. CommerceService; implements backend logic, e.g. database or ERP access

This is what I did in the past...

I agree with Bozho and Boris that the Service Layer shouldn't "know" about HttpR*.

Another approach to consider is putting an adapter (the sits between external services and your SL). This allows you to keep the SL clean of undesirable dependencies, and but the adapters give you the flexibility to integrate well with external systems where necessary; and because the adapter is isolated and only has one specific job to do it will be a flexible low risk option.