You don't traditionally try and transmit the entire CSLA-derived BO across via XML/SOAP. I'm not even sure you could, to be honest. IIS-hosted app servers still transmit binary-serialized BO's over HTTP.
The typical solution in this case is not to transmit the entire CSLA object, but to create DTO's and only transfer the data. FWIW, you could use DataTables/DataSets as your DTO's, but those are MS-specific objects, so your external XSD/WSDL administration might run into issues.
If you have Rocky's book (and you really should if you don't ![Smile [:)]](/emoticons/emotion-1.gif)
), read the chapter on web services. That's essentially what you're creating here. And if you want to be really fancy, and have Rocky's 3.0 e-book, you can see how you would implement a WCF service, so you can take advantage of all the WS-* goodness and throw even more buzzwords into your spec. It's the same technique as a "classic" ASP.NET web service, only using a different hammer to do the job.
HTH
- Scott
It's been a while since I read the chapter, and it may be that his example client app just uses the DTO's that are generated from the web service. But there is nothing stopping you from developing a solution where the web service and DTO's are the layer between your BO's on the client and server. You can use the same version of the BO's on both sides - indeed, you would have to. But you would have to write a custom portal/channel to interject the DTO process into the transfer.
Another possible option would be to take a look at the WebServicePortal Rocky wrote. It's part of CSLA, and it's covered in the book as well. Essentially, it takes your BO, serializes it into a byte stream, and sends that raw byte stream as a SOAP message. It's not an optimal solution - Rocky even says so - but it might serve your purposes. And the XSD and WSDL would be dirt simple, since you're sending raw byte arrays. Even if it doesn't, it could serve as a basis for the solution you create.
The bottom line is that, unfortunately, if you're being forced into "all web, all the time" (an unfortunate choice, IMHO), you will probably have to develop a slightly customized solution to transmit your BO's across the wire - especially if you don't have any control over the XSD/WSDL creation. But it is doable, and it's not a major programming effort. Plus, Rocky provides enough info in the book that you should be able to get there from here. And there's always the folks here on the forum, most of whom are smarter than I.
The kicker is that requirement that the data on the wire is
governed by an “external authority”. That means passing very
important things like IsNew/IsDeleted/etc will likely be impossible. If you don’t
control the data on the wire you are really in trouble – at least if you
want to clone your objects across the wire.
If all you want is XML on the wire, then switch to WCF. The WCF
data portal channel passes the data over the wire in XML format. But the actual
data is defined by a combination of your objects and the CSLA base classes. I
can’t imagine how you’d reconcile that with some external authority’s
idea of what is required on the wire – because you can bet good money
they aren’t think about the meta-state required to make the concept of
mobile objects work.
Rocky
From: tmg4340
[mailto:cslanet@lhotka.net]
Sent: Tuesday, January 22, 2008 2:26 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] CSLA & SOAP
It's been a
while since I read the chapter, and it may be that his example client app just
uses the DTO's that are generated from the web service. But there is
nothing stopping you from developing a solution where the web service and DTO's
are the layer between your BO's on the client and server. You can use the
same version of the BO's on both sides - indeed, you would have to. But
you would have to write a custom portal/channel to interject the DTO process
into the transfer.
Another
possible option would be to take a look at the WebServicePortal Rocky
wrote. It's part of CSLA, and it's covered in the book as well.
Essentially, it takes your BO, serializes it into a byte stream, and
sends that raw byte stream as a SOAP message. It's not an optimal
solution - Rocky even says so - but it might serve your purposes. And the
XSD and WSDL would be dirt simple, since you're sending raw byte arrays.
Even if it doesn't, it could serve as a basis for the solution you create.
The bottom
line is that, unfortunately, if you're being forced into "all web, all the
time" (an unfortunate choice, IMHO), you will probably have to develop a
slightly customized solution to transmit your BO's across the wire - especially
if you don't have any control over the XSD/WSDL creation. But it is
doable, and it's not a major programming effort. Plus, Rocky
provides enough info in the book that you should be able to get there from
here. And there's always the folks here on the forum, most of whom are
smarter than I.
mickeymouse:The Xml serialization is limited the public (read & write) fields and the class must have a public default constructor .
what about the methods of the object ?
One of the solution if I understood should be to create a DTO object ( who will match with one of the given xsd schema) during the transfert process
At the other end ( client or host ) the reception process will have to re-create the BO from the DTO received.
is it correct ?
Serialization - XML or otherwise - is only concerned with the data within the object. Nothing concerning the signature of the object is sent down the wire. That's why you have to have the assembly containing the object definition at both ends. .NET serialization creates an instance of the object based on the type name that comes with the data, so it's relying on the assembly manifest information to actually construct the object.
Conceptually, the process you've outlined is correct. However, as Rocky has already mentioned, you may run into several issues trying to get this to work. If you have no control over the XSD that you must work with, and if the "external authority" who is building it will not take your input, then you could be in trouble. While the object data will likely be handled just fine, unless they include the metadata that you would need to correctly populate properties like IsNew, IsDirty, IsDeleted, etc., you will not be able to construct the BO's on the server in such a way that they're going to be useful for updating the database.
(For what it's worth, it is my humble opinion that if those who are building your schema info do not take this metadata info into account, then you should find someone else. Essentially they are forcing you to use a SOA approach to your data management - how do they expect the server-side processes to know what to do with the data they receive? The answers to that question that do not involve passing metadata around are fairly poor, and will cause you nothing but headaches - whether you use CSLA or not...)
- Scott
Hello All,
All the XML schema messages (xsd) will be provided by an external certification administration .
The WSDL describing the web service will be provided by external certification administration.
You do realize that if you serialize your actual buisness objects in XML form, that you are then saying that this "external certification administration" is defining the very properties of your business objects?
What a horrible architectural limitation that would be! Your business objects very essense would be outside your control! What if you need some other data or a different shape to actually impleemnt your behaviors? Behaviors some external administration never considered?
What you are describing is exactly why you should use formal DTOs for data transfer. Let the external authority define what goes on the wire. If they get it wrong at least you aren't totally fubared, because you still control your internal implementation anyway...
Otherwise you are turning over your internal design to an external authority, and if I were in that position I'd be looking for a new job!
Copyright (c) Marimer LLC