CSLA & SOAP

CSLA & SOAP

Old forum URL: forums.lhotka.net/forums/t/4208.aspx


mickeymouse posted on Tuesday, January 22, 2008

Hello All,

Imagine I have this scenario and these specifications :

We have to build a solution with these specification:
*************************************************************************
The Implementers are REQUIRED to use this stack protocol :

Messaging uses XML
SOAP
HTTP
SSL
TCP
IP
Ethernet

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.

************************************************************************
Questions :
is it possible to use the CSLA.Net framework on both side ( Client & Host)  to build it ?
One idea :
The XSD schema provided by the admisnistration will be use for the facade  to the transport the real business Object on both side of the solution through their stack protocol .

So I was thinking something like that :

IE :

public class MyBusinessClass : BusinessBase

.........

public static MyBusinessClassXmlFacade ToXML ( MyBusinessClass  obj ) {
 ........
}

public static MyBusinessClass FromXML ( MyBusinessClassXmlFacade obj ) {
  ..........
}

What do you think and do you see other solution ?
Thanks

tmg4340 replied on Tuesday, January 22, 2008

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 [:)]), 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.  Smile [:)]  It's the same technique as a "classic" ASP.NET web service, only using a different hammer to do the job.

HTH

- Scott

mickeymouse replied on Tuesday, January 22, 2008

Thanks tmg4340,

I have the book and read the chapter 11 but in this chapter I think the client app web service just bind the DTO object to the visual component and the app do not reuse any BO object function of the real BO class.

My idea was to do the same kind of architecture and use the xsd schema provied by the administration as a DTO .

But the problem with this, you do not have the real copy of the object like with remoting. it's just a facade BO

So my thought was to recreate the BO object on the other size to be able to share the BO assembly on both side also and reuse the BO functions.

PS : do not forget we must use the given XSD & WSDL schema and must respect the stack protocol (for certification purpose) .
We  do not have any choice.

Thanks again


tmg4340 replied on Tuesday, January 22, 2008

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.

RockfordLhotka replied on Tuesday, January 22, 2008

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 replied on Tuesday, January 22, 2008

Thanks Rock,

I going to buy your ebook using CSLA.NEt 3.0 to take a look to WCF to try to find out the best approch with my spec and  obligatory requirements ( :-(  )

Thanks a lots



mickeymouse replied on Tuesday, January 22, 2008

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 ?

Thanks




tmg4340 replied on Tuesday, January 22, 2008

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

RockfordLhotka replied on Tuesday, January 22, 2008

mickeymouse:
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