I have a small Silverlight app, using WCF RIA for getting and manipulating data. I was thinking what modifications I have to make to port the app to WP7 or other platforms.
The DomainContext proxy generated in the SL app is not supported in WP7 afaik. (Am I right on this?)
So I think my options are exposing OData or SOAP (or JSON) endpoints for the DomainService. A lot of sources say that OData is pretty limited, but what about the DataServiceContext class? Is this almost as functional as the DomainContext? I mean it tracks my downloaded entities, and when I save the changes, it saves the tracked modifications to the server, and this is very useful I think.
But what about the SOAP endpoint, or platforms which don't have so many features like the WP7 DataServiceContext? How can I make modifications in this case? Do i have to track every change manually, and for example if I want to insert 45 entities, I have to insert them one-by-one with a basic insert (CRUD) method? (The generated service proxies are doing the same in the background btw?)
So to sum up my questions, which approach is the best, and the most platform independent? I think SOAP is the choice, but since I never developed on Android or iOS, i'm not sure. And also I'm not sure if I can send back IQueryable in every endpoint (or there is an equivalent on every platform?). If I can't, do i have to modify all my custom queries in the wcf ria domain service, to suite the limitations of SOAP?
Related
Starting from scratch in terms of knowledge I have written a desktop application using WPF and NHibernate. This has helped me get up to speed with both NHibernate and WPF.
However, there is a requirement to make the application so that it can be accessed from mutliple places - these include handheld devices which have very simple web browser (no javascript capability), web services, Internet, the desktop application and potentially other user interfaces.
I believe this requires moving the application from its current NHibernate.dll deployed on the client to a web based application. The sheer choice of technology stacks is overwhelming and I am hoping I can get pointed in the right direction.
In essence, I want to be able to access the data from the server side in the desktop client, from the web service, from the handheld devices.
On the server side I guess I would have a web server(IIS?), NHibernate and a database and some way of communicating between the clients and the server.
What would be the best choice in this circumstance? Is it REST? SOAP? WCF? Something I don't know about / haven't mentioned?
Any assistance and advice from people who have implemented similar things would be very much appreciated.
Well since you have already made most of the work on the desktop, moving the actual data access part on a webservice is not going to be hard.
If i were you i would make that transition and make a SOAP/WCF service have the same signatures (or at least as close as possible) as the data layer. This will make the transition for your already written desktop application easier. You will have to add code for synchronizing or just safety code for when the service is inaccesible.
For mobile access via a thin web client as the browser is, you are looking at a web site/application that touches the DB (possibly via the same data-access webservice) and generates html...
I can't advise between rest/soap/wcf as i have minor prior experience with all, but i can tell you that i have created a similar setup with a SOAP WebService feeding a Web Application and .NET Compact Framework Application for WM6+ and it works well.
I have a legacy dot net application (now migrated to .net 2.0).
We need to convert this application to silverlight.
Problem here is the datalayer. All the methods from the datalayer return datasets.
The entire web application is using datasets for databinding.
Now the questions are:
Can I use the same datasets for silverlight pages also?
Or do I have to create a wrapper around the datalayer?
Or do I have to change the entire datalayer architecture (like returning collections etc)?
Please suggest the best possible way.
Thanks,
SNA
Unfortunately, DataSets aren't supported in Silverlight 2 (and afaik aren't coming in Silverlight 3).
I'm going to assume that your current data layer has methods like GetTopCustomers that return DataSets, then the client application can modify that data and re-submit it to a data layer function like UpdateCustomers that takes a DataSet as a parameter and then submits changes to a database. If this is the case I think you'll have a tough time writing a wrapper because you'll be on your own for enforcing referential integrity and tracking changes on the client side. It's certainly possible but I think it'll be more pain than its worth. So imo creating a wrapper around your data layer would be equivalent to changing the entire data layer architecture to return collections, etc.
You best bet for a data layer is .NET RIA Services, which ships sometime in the Silverlight 3 timeframe. It's a huge leap over the current technology, ADO.NET Data Services, in that it adds change tracking and a DataSet-like "context" for the client. It also allows direct sharing of code between ASP.NET (or any part of the full .NET Framework) and Silverlight so your business rules can be run on both the client side and server side. Rewriting your data layer may not sound appealing, but I think it'll spare you much pain and you'll get a huge return if you choose .NET RIA Services. If that choice doesn't fit the other option is to use ADO.NET Data Services to ship the data back and forth (combined with a wrapper for your current data layer) or to write your own custom WCF services to provide CRUD operations (again with a wrapper on your current data layer).
Good luck!
If the goal of your conversion is to create a Silverlight version of your application with the least amount of change to your business logic layer, then a wrapper is your answer.
This is a lot of work in Silverlight V2, as you probably know. If you'd like some detail, here's a blog post. You will end up rolling your own serialize/deserialize/zip/encode layer for transferring the data to your Silverlight app.
Silverlight 3 isn't out yet, but close from the rumors. And this functionality is present in V3 (from what I hear).
I've been using Webservices so long.
But,so far up to what I know,I haven't found a solid point for using WCF over Webservices.
Webservices hosted with Cassini webserver = WCF?? Is that all?
Thanks
WCF is a communication stack that allows services to be exposed over HTTP (like ASMX) and TCP (like Remoting) as well as Named Pipes, MSMQ and with .NET 3.5 REST.
It allows this because it allows for decoupling the communcation parts of the service away from the business logic parts. All you need to do is decorate your service classes, methods and DTO's with the appropriate contract attribute ([SeriviceContract], [OperationContract] and [DataContract] respectivly.)
This had the benefit of being able to write a service once, and allowing many different kinds of clients to consume the same service (i.e. Java clients can use HTTP, .NET clients can use TCP, legacy can use MSMQ, etc.) using multiple bindings and endpoints.
WCF will still allow you do use all the features of each transport, including security, transactions, reliable messaging, etc., but you need to use some care. Not all features work on all transports, and you need to design accordingly. WCF allows you to specify in your contract which features are required. This prevents somone from trying to expose your service in a way that does not support the required feature set (i.e. if your service requires transactions, the WCF runtime will not allow the service to be accessed via a basic HTTP endpoint).
WCF is also highly extensible via custom behaviors (which influence how the WCF runtime works) and custom channels (which control how WCF services communicate with the outside world.)
WCF has a bit of a learning curve compared to ASMX, but the benefits ABSOLUTLY out weight this learning curve.
WCF is an much larger communication framework that offers support for web services, message queues, TCP-based connections, named-pipes, RESTful services, etc. It allows you to host a service in different ways (IIS, console app, windows service, winforms app, etc.) with any number of different types of endpoints.
To answer your question, if your web-service is an .asmx service, then you are not using WCF. If you service uses classes from the System.ServiceModel namespace, or your config file includes a <system.serviceModel> section, then you are using WCF. I'm not sure if Cassini supports WCF.
A couple of pretty big advantages would be multiple end point binding, greater support for WS-* standards, it can be self hosting and has transaction management for a start.
There are some rumors floating around that the team at my company will soon be using web services for all future application development. The architecture is supposed to be something like this:
Application --> Web Service --> Database
The stated reasoning behind it is security. This sounds like a huge waste of time for little if any benefit. My question is, in what ways does a web service make your data more secure than a database? I would think that if an attacker wanted to get all your data and had already gotten onto the app server, it would be fairly trivial to figure out how the application is getting it's data.
Please keep in mind that these web services would be purely for data, and would have little if any business/validation logic, and would also be outside the application developers control (at least that's the way it's worked with all previous applications that have used web services).
If it's true that there will be no business logic or validation on the web services, then there is only a limited security benefit to adding the additional layer of abstraction. I say limited because the interface between your application and the database is still more limited than if they were directly talking to each other.
If you add validation and business logic to the equation, there is a significant security benefit, as anyone who has access to the application account can only do the database what the application is able to do. Additionally, this is a better design because it reduces coupling between your application and implementation details of how the data is stored in the database. If you wanted to change the database schema, you only need to update the web services, and not entire applications.
One important thing about Web Services is interoperability so that different applications from different platforms later can utilize the services and data. Your company will benefit a lot by doing so. And you are right about the security, it is definitely one of the good reasons to use web service rather than expose a public endpoint of the database, it is dangerous!
Web Services enable the accessibility of your data, For example, your data can be accessed within browser by javascript. There is no way to access the database on the server directly within Javascript.
All in all, go for it, that is the right approach.
the security argument is questionable; authenticating to a web service is no different than authenticating to the database
there are legitimate reasons for moving db operations to web services and SOA in general, but security isn't one of them
If you use a webservice hopefully you will also be using some kind of queue when sending the data to the database. If you are using a webservice and queue combo then the security come into place with less chance of lost data. If you do not have a webservice and queue combo if you send data to the database and it never gets there you have no were for it to go it just disappears.
You are correct though if someone wants to break into your system a webservice isnt going to help if anything it might make it worse if you make the webservice public and they find the name of your webservice because then they can just query your DB using the webservice and any security features on your servers will just think it is you applications getting the information.
My colleague has found himself in an "interesting" situation. He is working on a Silverlight (2.0) prototype that needs to call existing web services in the enterprise and bind the returned data to data-display controls. The thing is, the web services return .NET DataSets (they are not about to change existing implementations) and Silverlight does not natively support DataSets.
What would a good workaround be? I was thinking an adapter pattern but do not know if middle-man web services to carry out transformations would be a very good idea. Could be tedious if there are many existing web services.
AFAIK, when a .NET web service returns a DataSet, it returns its XML representation (which is pretty friendly). The fact that a .NET client can consume the DataSet directly only abstracts the fact that an Xml Serialization-Deserialization is taking place.
So I would manually query the web services you require, observe the generated XML, and then parse it in the client side.
Another possibility is to take advantage of the fact that Web Services use the standard XML Serializer, so you could create the C# classes from the returned schema and then let the XmlSerializer automatically handle it. I'm not sure if the code generated by the XSD.exe tool will be Silverlight friendly, but it is worth giving it a shot.
Try the following: http://silverlightdataset.net
The dangers and general nastyness of Datasets eh. I would use a generic proxy that is responsible for consuming the webmethod and transforming the dataset into xml/json
Yup, silverlight ds is a great solution, they even have relationships built into it