What's the reasoning behind MobileRequestProcessor's delegation of request call to Csla.DataPortal (client DataPortal) rather than Csla.Server.DataPortal (server one) as Csla.Server.Hosts.WcfPortal (regular Wcf Portal) does?
If I've got it correctly, this delegation will bring up Local Proxy on the server and will ultimately end on Csla.Server.DataPortal as well, but why is it needed?
Thanks,
--- ngm
This approach allows your web server code to leverage the full data portal behavior for routing requests.
Most importantly, you might choose to use something other than the WCF channel to communicate with your app server, so delegating to WcfProxy or WcfPortal would be bad as it would eliminate all your flexibility.
But also, this approach allows you to have a smart custom proxy running on the web server to route different calls to different app servers, etc.
In short, it enables a lot of advanced scenarios that people might want in some cases.
Rocky,
Thank you for a prompt reply.
I'm not quite sure I see those benefits. It might be that the explanation is too abstract or it might be me.
Basically, the request already selected the proper proxy (in this case Wcf Proxy) which in turn selected proper host (in this case Mobile Wcf Portal), now the only question is how is the request routed to Server.DataPortal after transport technology is out of equation.
I absolutely don't see the value of going through additional layer of indirection i.e. Client Data Portal which is pretty much LocalProxy unless that server is configured to point to some other application server.
Whatsoever, despite possible performance degradation, it looks to me that this indirection can mask the real request's context in that it can look like the business code will infer it's being executed as part of the local execution and not the remote one. Let's consider ApplicationContext.ExecutionLocation, it's being set in SetContext method of Server.DataPortal which in this case is called from LocalProxy. That masks context of the original request (yes the value of ApplicationContext.ExecuteLocation is Client in case of WcfProxy / Mobile WcfPortal).
However, if "jumping from Data Portal to another Data Portal" scenario is to be achieved, that should be left to business developer to implement in data access i.e. she can invoke any type of Data Portal proxy (including local one) from there and thus keep chaining them as long as she wants.
On the other hand the check for Object Factory block of MobileRequestProcessor seems to go in totally opposite direction. It skips Server.DataPortal completely. What it means is that it will in turn skip the transactional support alogether.
Am I missing something seriously here? If so, what's the reason for this disparity?
Thanks,
- ngm
Just to level set: we are talking about a 4-tier physical deployment, where a smart client makes a call to a web server, and the web server delegates that call to an app server via the data portal.
The design scenario I'm focused on here is one where you don't fully trust the client. So an honest client does a lot of processing and work, thus giving the user a rich and happy experience. It then sends a request to the web server. A hacked client might do invalid calculations, or generate incorrect data which is sent to the web server.
On the web server you have the option to re-run the business logic on the web server (the same logic as on the client) because you trust the web server more than the client. Or the web server can act as a simple passthrough. Or the web server can apply specialized authorization or verification logic to decide if it wants to accept the client request.
The great thing is that all this has occurred outside the real firewall that protects the app server and database server. So now a would-be hacker must compromise the client, and the web server, and probably discover the alternate ports/protocol used to get through that second firewall.
Just because you used WCF to get from the client to the web server doesn't mean you can't switch protocols to get from the web server to the app server.
What's even more fun is that the web server can do some caching (because it is generally trusted). So some data portal calls might be handled local to the web server, while others are actually routed to the app server behind the second firewall.
Got it.
But you're envisioning (politely for dreaming 
) and I'm with my plumbing questions in the mine 2000 ft. under the earth 
However, I had the solution that implemented similar scenario in CSLA. It was certain app BOs that interact on few occasions with my company's BOs. Scenarios range from error logging, licensing to telemetry. The similarity was that two Data Portals were involved, one app specific - deployed on- premise and another one within my company's infrastructure. The difference is that this was part of business logic i.e. app BO when on-premises Data Portal interacts with our infrastructure BO which ultimately talks with our Data Portal, but here you're talking more about system wide setup where this is enforced for every request.
Back to the plumbing, Object Factory version of invocation doesn't follow this path and it's much more "bare bone" then DataPortal_XYZ version. Similarly, non-mobile Wcf Poral doesn't advocate this approach but rather goes to Server.DataPortal directly. Shouldn't they all be equal with supported functionalities such as transactions?
- ngm
Copyright (c) Marimer LLC