opened
rmotta01
username_0
Hi, I'm new to CSLA. I'm reading the source code and Rockford's blog to understand the framework, but I have a two questions related to the DataPortal and the Mobile Object pattern:

1)Do NetDataContractSerializer and MobileFormatter treat objects as references? I mean, If I have several references to an object in an object graph, only one copy of the object is serialized, deserialized and referenced at the other endpoint?

2)Can an endpoint exposed outside the firewall use the Mobile Object pattern or it has to be SOA? 
For example, the UI tier, a WPF or smartphone app running outside the firewall, exchanging data with an WCF service. Can we trust the data that the WCF Service is receiving? 
I don't think so. An individual could send invalid data to the server modifying the client app or without even using the client app. Validation has to happen at both sides.
The WCF service can't trust in the object graph that the UI tier is sending. For example, an "Order" is related to a "Customer", the Customer sent by the client could have incorrect data to break the system. The server has to get the Customer again from the database.
Other example is the original state of objects. The server should get the original state from the database and merge it with the new state that the client is sending.

So, in this case tiers could share the implementation of the business objects, but they can't use the Mobile Object pattern to communicate, they have to use SOA to enforce the trust boundary and reconstruct the objects manually. Is this the recommended practice when the UI tier outside the firewall?


Thanks.
Mobile Object pattern questions
issue
created
rockfordlhotka
username_1
1. Short answer: yes. Long answer: CSLA relies on serialization with full fidelity - meaning private fields, public fields, and object references remain intact. As a result it only works with BinaryFormatter, NDCS, and MobileFormatter because those serializers are able to maintain things like object references (unlike XmlSerializer, JsonSerializer, DCS, etc.).
1. The external endpoint can absolutely be a data portal endpoint, and that is the most common scenario. But you need to decide what kind of client scenarios you want to support, because the data portal endpoint can only be consumed by a data portal (CSLA) client. If you need to support unknown clients that may not use CSLA then you should *not* expose your data portal endpoint, but rather should implement a formal service-oriented API, probably following good REST practices. The data portal supports n-tier scenarios, where SOA is *not* n-tier, but rather is a way for *totally independent applications* to interact via messages.
comment
created
rockfordlhotka
username_1
http://www.lhotka.net/weblog/CategoryView,category,Service-Oriented.aspx
comment
created
rmotta01
username_0
Rockford, thanks for answering.

1)Full fidelity make sense. 

2)I think we cannot trust in the client app even if we developed it, using the same shared library of business logic, because a malicious user could modify the client app decompiling the .NET assembly and recompiling it with new logic that send incorrect that to the service. Or a malicious user could bypass the client app altogether sending incorrect data directly to the service.
In the case of a web server as UI tier, trusting is easy because servers are protected by many security measures, but that's not the case for a client app distributed to many users in different locations.
For example, in an Order app, the service can't use the Customer instance that the client app is sending, because the client could have been tampered to send incorrect Customer data to bypass validation rules of the Order. The service has to load a new instance of the Customer from the database and replace the references to it in the object graph sent by the client.
comment
created
rockfordlhotka
username_1
Your second point is valid. One way to handle this is to ensure that the rules are re-run on the app server at the start of every data portal request.

Your other option is to write and maintain the business logic twice - knowing that whether you write it twice or not the client-side logic is vulnerable. So either way you need to run the logic again on the server.

In other words, the problem of not trusting the client exists in n-tier and SOA worlds, and the solution is to ensure that the rules run on the server. 

That doesn't mean you *can't also* run the rules on the client, nor does it mean you have to write and maintain the rules twice.

The server-side data portal has the ability for you to hook into the request pipeline and rerun all rules in your object graph before allowing further processing on the server.
comment
created
rockfordlhotka
username_1
So again, the real question between n-tier and SOA isn't whether you trust the client - it is whether you *know* the client, or will be supporting unknown clients that might be built with arbitrary technologies outside of your control.
comment
created
rmotta01
username_0
Yes, validation rules should run in the server again, but that's not enough.

Trust is the key factor. If the service doesn't trust the client, It should only accept data that it doesn't have, the NEW data of the use case. For example, in an Order app, the server should only receive the Order and Detail lines, but It shouldn't accept related entities like: Customer, Product, Address, etc, because these entities could have fake data as an intent to deceive the server. The server has to get those entities from the database. The same applies to context data.

In theory, Mobile Objects could still be used with untrustworthy clients, but the service has to dismiss all the data that is not secure and replace it with data from the database. There is a risk of making a mistake failing to dismiss client data and use it as part of the validation, specially if the object graph is complex.

SOA is useful because it enforce this principle. It defines explicitly the data that the server will receive, there is no additional task of dismissing insecure data, task that could be neglected. There is no good  reason to incur in the overhead and security risk of sending the complete object graph from the client to the server, if the server as a requisite has to dismiss most of it.

Client and server can still share the business logic using CSLA objects, but without trust they shouldn't use mobile objects to communicate, at least in messages from client to server. CLSA business objects could be reconstructed at the server from DTOs and data from the database.

I see trust as a prerequisite of Mobile Objects, what do you think?
comment
created
rockfordlhotka
username_1
Your points are extremely valid.
comment
created
rmotta01
username_0
Ok, more work to do.
comment