Hi I’m new to CSLA and CSLA light. We have a requirement to build a WPF client with a central CSLA application server. It would be desirable if the application could operate within the local intranet and over the web. For example the user has the application installed on their laptop which the use in their place of work. They then can take the laptop home and still should be able to connect to the same application server over the web.
The question is, would we need to use CSLA light to achieve this. I don't think it’s possible with just CSLA .net because the business objects don't serialize to xml without using CSLA light. How would the CSLA light business objects work with a WPF client?
WPF and Silverlight are both client technologies, so your question doesn't entirely make sense.
You can build a WPF client that talks to an app server using CSLA .NET for Windows.
You can build a Silverlight client that talks to an app server by using CSLA .NET for Silverlight on the client and CSLA .NET for Windows on the server.
I don't know why you'd do this, but you could create both WPF and Silverlight clients that talk to the same app server. But that seems silly, since if you can create the client in Silverlight, then why bother with WPF at all?
In any case, the data portal takes care of the communication between the client and the app server. It is true that the details around serialization are different with a Silverlight client as compared to any .NET client - but those differences are essentially invisible to you because the data portal takes care of the details.
Thanks for the quick reply.
I don't think you have really answered the question. At the moment we have no plans to create a silver light client we just wanted to leverage our WPF build so that it could work over the internet. A windows based client can call a service just as easily as a browser based one. We would just like to confirm our options.
What you state in the last part of your post is that we would be supported by the CSLA framework if we had two different applications. But this would really mean
1.) A WPF running in the local intranet only. Not web enabled (CSLA .NET).
2.) A Silver light application that’s web enabled (CSLA Light).
The reason I asked about CSLA Light was because it was generating DTO's on the fly to enable communication over the web. The CSLA .NET objects won't serialize to xml? So CSLA.NET objects are not web enabled?
We thought we could maybe leverage the CSLA light framework to help us with the serialization part. Although we probably wouldn’t need to use CSLA light because the Imobileobject interface is already implemented in CSLA .NET. However there is no CSLA .NET based client data portal expecting an xml DTO instead of a binary object. Only the CSLA light based client is expecting data serialized through the IMobileObject interface not a CSLA .NET client? We would probably have to create our own client data portal? Not something we should attempt lightly? Or is all cross process communication now done via Imobileobject interface?
Note : Please correct me if what have stated in the paragraph above is wrong. I’m still a CSLA newbie and it takes a while to get through your book and blogs.
You have a point though, if we wanted an app to operate over the internet we should build a silver light one and use that app on the local intranet as well.
I don’t understand why you want an (inefficient) XML message to
go over the wire.
There are other threads on the forum right now where people are
figuring out how to STOP the transfer of XML by getting WCF to use binary
encoding (binary XML). The reason is because XML is so bloated and inefficient
that it causes perf issues.
The .NET data portal can use WCF (which I recommend). If you use
WCF for communication it will work great in intranet and internet settings.
True, the data over the wire is binary encoded, but that is a good thing
because the alternative is sending 5-10x more bytes over the wire to get the
same data transferred.
The data portal is designed for n-tier client/server
communication. While it is service-based in its design, it doesn’t create “SOA
services” for use by other applications. And that’s OK, because it provides
much better perf and data size than you’d get with an open XML model.
If you want to create SOA services, you should read Chapter 21
of the Expert 2008 Business Objects book. In that case you would be
creating two separate applications – a client application and a server
application. They’d communicate over the internet using XML messages. But they’d
be separate applications, and should share no code artifacts (because that
would defeat the whole point of being service oriented).
Again thanks for the answers and the quick response.
Its not that we want to create a WPF client thats strictly xml based. We wanted the flexibility to run binary communication over the intranet and xml communications over the web. We wanted the app to be able to switch over easily between binary and xml and we wanted to stay within the CSLA framework. We didn't want to create extra services.
When I think it over more I can see that this isn't strictly tied to the CSLA framework. I'm not sure how we would get WCF to switch over on the client. We would also need to expose more than one data portal (not service) on the server.
We would certainly want to use Binary XML (I thought this was part of the latest CSLA beta release?).
Our reasoning followed along the lines of, if the CSLA .NET server could talk to the silver light client through the new Imobileobject interface based communication. That is, it takes the CSLA light xml serialized data in and then re-inflates it to a CSLA .NET object then the ability to do what we wanted is already in the framework. Its maybe just not in CSLA .Net dataportal. If we could achieve this while using binary xml for the communication then thats even better.
Again we are just kicking around the options to see whats possible with the least amount of effort. We would like to avoide having to drop a new service layer between the client and application server.
Wouldn't it be much simpler to use WPF at work and home as the client and just set up a VPN connection to the app server?
Joe
Hi Joe,
It would if every client of our application agreeded to doing that. Right at the moment i'm not sure that they would because I don't know who will end up buying it and what kind of policy they have in place.
The one thing you should consider when using the data portal
over the internet is of course security. And the simplest solution is to use
https instead of http, which you can easily do with WCF. WCF also has its own
x509 security model, so if you don’t have https capability for some reason, you
can install a server certificate and use WCF encryption instead – which gets
you to the same end result as https.
So to summarize my 3 options are.
1.) WPF client with CSLA .Net and VPN.
2.) WPF client supported with WCF SOA services.
3.) Silver light client with CSLA light.
Thanks for the answers and support. It is much appreciated.
What’s wrong with
4.) WPF client with CSLA .NET using SSL.
??
Ok,
I must be missing something in my understanding of whats possible with serialization over the web. What your saying is I can serialize to binary and send my CSLA .NET object over the web as long as i'm using SSL?
I did not think that was possible.
When I tried to binary serialize some my objects for my local windows firewall started complaining. Switching to soap serialization stops that. So just to be clear your saying there is no problems going through firewalls using binary serialization over the web? If that was the case why would SOAP and web services have been created?
Interoperability aside I thought one of the big things that XML was never stopped by firewalls.
I'm really confused now. Why would you need to create DTO's on the fly for the CSLA light if you could have just sent through binary serialized CSLA .NET objects?
> I'm really confused now. Why would you need to
> create DTO's on the fly for the CSLA light if you
> could have just sent through binary serialized CSLA
.NET objects?
The .NET framework has something called the BinaryFormatter,
which is capable of cloning an object graph.
CSLA .NET relies on the ability to clone an object graph.
Things like the XmlSerializer, JsonSerializer,
DataContractSerializer, DataContractJsonSerializer, etc. cannot clone an object
graph.
Silverlight does not have the BinaryFormatter, so we had to
write an equivalent. The easiest way to write an equivalent was to do a transform
of the object graph into a flatter object structure. We chose to build that
flatter object structure as a set of DTOs so we could use existing serializers
to get them over the wire – just because that saved us a lot of effort.
Our goal was NOT to get to XML (yuck!), but rather was to get
the object graph data into a form where existing serializers could do much of
the heavy work for us. It just turns out that the only serializers on
Silverlight go to XML or JSON, and according to the PM I talked to on the
Silverlight WCF team, the XML serialization is typically faster than the JSON
serialization.
Personally I’d much prefer a binary serializer. It would
be faster, and would result in much smaller data on the wire. But there isn’t
such a thing on Silverlight…
This is a common misconception about the web.
The web is just a series of tubes – no, sorry, that’s
true only in Alaska. :)
The web is NO DIFFERENT FROM YOUR LAN – it connects your
computers to each other through the TCP/IP protocol. In general terms, if you
can do something on your local network, you can do it on the Internet if you
can connect to the computers.
WCF on the intranet is exactly the same as WCF of the
Internet.
Much Internet traffic is binary btw. Images, audio files, video
files. Text data transfer obviously happens a lot, but it is the rare web page
that is pure text and doesn’t include a ton of images (binary) or Flash
apps (binary), etc.
WCF can transfer XML, JSON and binary data. The choice of which
format is up to you and your needs. Binary is often the smallest/fastest so it
is good for n-tier apps, but isn’t good for open data exchange between
apps. That’s where XML and JSON come into play.
If you are using the data portal you are doing n-tier, and so
you are communicating between tiers of your own application. No need for
open data exchange, but definitely a need for size/speed optimization.
So then the only real difference between the Internet and
intranet is security. On the intranet you often have a level of trust of the
network itself – not worrying overmuch about man-in-the-middle attacks.
But on the Internet you might worry about that sort of attack, and the easy
solution is to use SSL.
I say might worry, because a lot of web apps don’t
use SSL, so clearly those apps aren’t worried about data attacks. And if
your app would fit that category, then you can use the data portal without SSL
too, and achieve the same (or probably better) security. I say probably better,
because the binary data transferred by the data portal is already obfuscated,
unlike the HTML transferred by a web app – so you’ve already raised
the bar a little in terms of data protection.
Again thanks for the response and this is great information.
As you state we have always been able to send binary over the internet in the form of images etc. I've always viewed that as the content of a web page. It’s a little different talking to a remote object but in the end you are right. Both are using HTTP to communicate.
My question now is centred on implementation.
In your 2005 book you mentioned using web services returning byte arrays which contained manually serialized business objects. ajj3085 mentioned that CSLA objects could always be sent over the web. (In the 2008 book I don't see this mentioned. I'll take another read through chapter 21. )
Looking through info on WCF I see that can perform binary over http using custom binding. This is nothing new; .NET remoting objects usually used that. So when you say we can use WCF and binary serialization over the internet are you talking about binary over http or something like MTOM? I see MTOM as something similar to byte array solution in your 2005 book. If we can use binary over http can we still host our WCF data portal in WAS or do we need to create a custom host.
Sorry for all these questions. I'm still scanning the forums and the web for answers. If I’m still off track in what I am asking please let me know.
Don't worry i'm not ignoring security i'm just trying to get the serialization and communication correct first. Then again using the SSL really implies WCF web services? So are we talking about communication in WCF using MTOM?
I see you have a lot of questions in the forum. I'll scan the forum more and ask less :)
MTOM isn’t required. If you use SSL, your communications are
protected. And you can use SSL with Remoting, asmx web services or WCF – all of
which are supported by the data portal.
I think you are overcomplicating the issue.
The data portal works great over the internet, especially with
WCF, but also with asmx or Remoting.
This isn’t something you should have to worry about – it just
works.
But you should worry about two things: performance and security.
Binary XML can help with performance, because it shrinks the
size of the byte stream generated by WCF.
SSL can provide security, and is (for more orgs) easy to
implement because you just switch to https URLs, tweak the WCF config to use
transport security and you are done.
Ok great. I'll give that a try.
With this i'm staying within the framework and not creating any new services like you describe in chapter 21.
I don't need XML services because i'm not interested in interoperbility I just want to get web enabled.
Copyright (c) Marimer LLC