CSLA Web Service Interoperability or lack of

CSLA Web Service Interoperability or lack of

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


srnichols posted on Friday, September 12, 2008

Looking for any suggestions on the best way to expose your CSLA objects as heterogeneous SOAP web services that other platforms can consume?  Basically, we have Java and Adobe Flex apps that need to consume data from our CSLA applications API.  The problem I am seeing is that the WCF message CSLA returns is basically a SOAP packet that just raps the .Net object (base64 encode).   These other teams are expecting a nicely formatted SOAP message that they can easily read and work with.  Not an encoded .Net object.  

 

Anyone else have problems like this?  How did you get around it?           

Fintanv replied on Friday, September 12, 2008

I have not yet delved into the world of WCF so forgive if this is not relevant, but in the past I have exposed CSLA BO's via web services by putting a thin layer in between, that use DTO's.  The web method would call the BO and get back the object, then use the object to load the DTO which would be returned to the client.  A little extra overhead, but it protects the web service contract from change in your underlying BO's. 

-- Fintan

srnichols replied on Friday, September 12, 2008

Well there can’t be that many "Fintan‘s"  that use CSLA and the V must be for “Van Ommen Kloeke”, hast to be.   Great to see you are still working with CSLA.   I left our old employer and am now playing application architect for another large company in the valley.    Trying to get them to see the goodness of CSLA and not make the same mistake we made by building our own BO framework.  I don’t want to go through that again. 

 

What you wrote makes sense,  I figured I might have to do some type of abstraction web service layer over my CSLA BO’s to make those Java guys happy, was just hoping there might be an easier way.

 

Talk later

-Scott Nichols    

RockfordLhotka replied on Friday, September 12, 2008

The data portal is absolutely NOT intended to be used for interoperable SOA. It is designed to clone objects between client and app server.

Chapter 11 discusses the techniques you should use when implementing message-based services.

srnichols replied on Friday, September 12, 2008

Thanks for the fast response Rocky!

Yep, Chap 11 confirmed what I needed to know, its. been a couple of years since I read the book, forgot about that chapter.   

tarekahf replied on Friday, September 12, 2008

I hope this method will also work with Adobe LiveCycle Forms, since they support connecting a standard .NET WSDL interface.

I once developed a simple .NET Web Service Example (not using CSLA) and it worked easily with Adobe LC Form as a front-end (when run under Acrobat 7.0.5 and above).

I am making the assumption here is that if it worked with Standard .NET web service interface, there is noting that will stop it for working with the CSLA Version of the same !

RockfordLhotka replied on Friday, September 12, 2008

If you follow the techniques in chapter 11, it is entirely up to you (and either asmx or WCF) as to whether your service can be consumed by other technologies.

 

If Adobe’s technology works with standard WSDL, then it should work with asmx web services, or WCF with basicHttpBinding.

 

But none of that has anything at all to do with CSLA – that is purely a matter of the service interface you implement.

 

Rocky

Copyright (c) Marimer LLC