The whole idea of the DataPortal is that your server in the DMZ can *avoid* talking directly to the DB and instead talk to an app server (Web Server) located on the other side of the firewall (inside Corporate.)
For this you simply need to follow standard CSLA coding techniques (mainly no DB communications unless you are in a Dataportal_xyz method.)
Then you can switch between local dataportal (the web server can talk to tthe DB server) and a remote dataportal (your web server talks to a 2nd web server which talks tot he DB for you) by changing your config file.
The BOs are shuttled back and forth through the DataPortal automatically because they are serializable.
You can begin implementing WCF as the Remoting mechanism - but be sure to get the eBook before even thinking about it. There is a lot of information there which you should know before deciding if it is worth it.
Joe
Can we just clarify the situation you are describing. Are you talking about a situation where you have the following physical requirements.
The web server is an externally hosted server outside the control of the corporation. This will communicate with an App server that is inside the "outer" corporate firewall, but outside the "inner" corporate firewall (I believe that is what you mean by inside the DMZ).
There is a "primary" App server inside the DMZ that for security reasons cannot communicate through the "inner" firewall to access the DB. Therefore you want to configure the "primary" App server to communicate with a "secondary" App server that is inside the "inner" firewall.
The "secondary" App server is inside the "inner" firewall and this server does have access to the DB server. This server will perform all SQL requests against the DB.
Have I understood the situation correctly?
I thought that's what you were getting at ![Smile [:)]](/emoticons/emotion-1.gif)
. That's an interesting configuration problem you have there.
I wonder if Rocky, or someone else at Magenic, has already had experience with that type of configuration?
It's an obvious web-based scenario that you are describing.
Actually, I've just had a further thought on this topic based on some other work we are doing with Exchange Server 2007.
I think, the key thing here is that you don't want to de-serialize the objects in the DMZ. You really only want to do that when reach the "inner" App server.
So what you need in the DMZ is a relay service. Something that takes the request, but immediately passes it on to the ultimate target.
So we managed to achieve something like this using a Web Service wrapper that sits around the Web Service API for Exchange Server 2007. "Our" Web Service runs on a server and just takes the request and forwards it to the real Exchange Server Web Service with no de-serialization. And as far as the client consumer is concerned it looks like the request was handled by our Web Service.
If you used Web Services as the transport in both cases that might solve the problem.
Is that a possibility?
ajj3085:
I think there was a similar "relay" requirement discussed on this forum before. Rocky's suggestion was to implement a dataportal which handled this relaying. It would be similar to remoting, for example, that simply does the remoting call then passes to the simple data portal. In this case, it would pass it to whatever dataportal is configured on the app server.
Yes, this was my recommendation.
I think the overall architecture here is pretty iffy. It seems like the relay "app server" does nothing but add overhead to the solution.
But if you do need a data portal relay, it wouldn't be that hard to write. Just create a data portal service/host like I do in Chapter 4. The data portal is all interface based, so all you need to do is create objects with the right interface so the message gets routed to your relay object. Your relay object would then contact the real app server and just pass the message along. That real app server would run a normal data portal configuration.
Copyright (c) Marimer LLC