We are about to start a new project for a server application, for the purpose of collecting data from several data sources and storing it in a database.
For a quick test, we created a WinForms app which uses the core functionality from a custom library, and now have to start migrating it towards the final product.
From what we've done so far, the best way to do this should be to make it a Windows service and then expose basic monitoring and configuration to a thin Win or Web client through remoting/web services.
Is there a more appropriate way to make such an application?
You could consider exposing the service itself using the WCF/ADO.NET Data Services: http://msdn.microsoft.com/en-us/library/cc668792.aspx
Also see this for a quick walkthrough on how to expose a WCF Data Service: http://www.msteched.com/2010/NorthAmerica/DEV324
Related
We are in process of re designing an old windows client server based application to web based application.
This application is built in C# using Remoting and WCF. On client side its Windows and WPF.
My Queries
What all concepts should be taken care when we make this application web based?
What design patterns should be followed for Web Based Architecture?
In WCF part we are using Net TCP Binding which can be easily migrated to HttpBinding, but I am more concern over Remoting, will it able to Serve the purpose, means can Remoting serve the purpose when Http calls are being made?
I would probably merge "remoting" with wcf and use httpbinding endpoint. font-end you could decide to use MVC pattern which will give you a better performance.
Sorry to answer your question with a question but: From an architecture or business point of view, why would you want to do this?
Your original application uses Remoting, which does not work over the Internet, therefore I am assuming that this is an internal application.
A web application would have the following tiers:
The presentation which runs on the browser
The Web Server which sends the pages to the browser
The application server which would host your WCF services
The database server
As you see the web application in the browser does not call the services directly (unless you use REST based services)
I am new to silverlight, WCF RIA services. We have a medium size financial business web application. There is a lot of code. The code is well organized with lots of business objects, web controls, web forms, Data Access layer, Business logic layer.
There is a requirement for some enhancements to the web application and one of the team member wants to use silverlight to improve UI and responsiveness.
We tried to integrate a small silverlight application in the web application, But what I found is we copy the xap file and it always opens the Main form.
how can we open other silverlight controls?
How can we use the business objects and business logic with the silverlight as the silverlight supports on silverlight class library?
How can we use the existing data access library?
How can we connect to the database? I saw WCF RIA services, all the examples I saw with entity framework and we use oracle and the cannot use the beta version of oracle entity framework?
how to pass data to & from silverlight app to asp.net?
There maybe some other issues which I am unaware.
Thanks, Naveen
how can we open other silverlight controls?
You would create a Navigation Framework based Silverlight application. This allows the use of a path following # in the URL to navigate to other pages within the Silverlight application.
How can we use the business objects and business logic with the silverlight as the silverlight supports on silverlight class library?
You won't be able to use them directly. Here you would create a Silverlight WCF service to access your business objects, you keep the business objects on the server.
How can we use the existing data access library?
You don't, you are going via WCF to your business objects which are on the server and from there on to your data.
How can we connect to the database? I saw WCF RIA services, all the examples I saw with entity framework and we use oracle and the cannot use the beta version of oracle entity framework?
As above, the Silverlight app only sees your specialist WCF Service.
how to pass data to & from silverlight app to asp.net?
You can do that via your business objects and/or your new WCF Service.
We have an application in which we have created a service layer with most of the business logic and utility services (logging, exceptions, caching etc). We have to come with a way to expose this service as an API to the UI components. Here are some of our requirements:
We would like to create multiple
components based on the service.
We would like third party developers
to use our service to create their
own components or utilize our data.
For scalability we would like to have
a multiple instances installed on
different boxes. Similarly there
could be more than an instance of the
same UI component.
One way to expose the service layer is to host it under a REST based WCF layer.
The other way is to host the service in model layer of an ASP.Net MVC project. The UI components will be hosted in MVC projects of their own. The Javascript in the views of UI components will directly call the controllers of service project.
WCF is supposed to be very heavyweight option. On the other hand I am not too convinced with the MVC approach as I feel that this is not purpose it is meant for.
Could you please recommend me a way in Microsoft world to expose our service layer.
WCF seems to be the way to go here. Although WCF started out (in my oppinion) as a beast, it got tamed over the years with better HTTP and JSON support and less custom configuration (although still allowing you to modefy basicly every little aspect of your service).
Exposing your current service layer as a REST Service is a breeze and allows your customers/yourself to easily consume it on any device that supports HTTP.
See: http://codebetter.com/glennblock/2010/11/01/wcf-web-apis-http-your-way/
Models are not services. Models are POCOs that hold data.
You can expose your service through a WCF Service, and let your ASP.NET MVC app consume it. If you're always sure that the service will run on the same box as the client app, you can use named pipes for transport -- then the overhead of WCF is minimal, compared to the advantages.
WCF seems to be the direction that Microsoft is headed for this and for good reason. WCF services are the best option here because you mentioned third-party development support. Because these web services are defined by a WSDL, they are cross platform and can be consumed by non .NET applications.
It perfectly seperates your service layer to be consumed by ANY components.
Following the KISS principle, I suddenly realised the following:
In .NET, you can use the Entity Model Framework to wrap around a database.
This model can be exposed as a web service through WCF.
This web service would have a very standardized definition.
A client application could be created which could consume any such RESTful web service.
I don't want to re-invent the wheel and it wouldn't surprise me if someone has already done this, so my question is simple: Has anyone already created a simple (desktop, not web) client application that can consume a RESTful service that's based on the Entity Framework and which will allow the user to read and write data directly to this service?
Otherwise, I'll just have to "invent" this myself. :-)Problem is, the database layer and RESTful service is already finished. The RESTful service will only stay in the project during it's development phase, since we can use the database-layer assembly directly from the web applications that are build around it. When the web application is deployed, the RESTful services are just kept out of the deployment.
But the database has a lot of data to manage over nearly 50 tables. When developing against a local database, we can have straight access to the database so I wouldn't need this tool for this. When it's deployed, the web application would be the only way to access the data so I could not use this tool. But we're also having a test phase where the database is stored on another system outside the local domain and this database is not available for developers. Only administrators have direct access to this database, making tests a bit more complex.
However, through the RESTful service, I can still access the data directly. Thus, when some test goes wrong, I can repair the data through this connection or just create a copy of the data for tests on my local system. There's plenty of other functionality and it's even possible to just open the URL to a table service straight in Excel or XMLSpy to see the contents. But when I want to write something back, I have to write special code to do just that. A generic tool that would allow me to access the data and modify it would be easier. Since it's a generic setup around the ADO.NET Data services, this should be reasonable easy too.
Thus, I can do it but hoped someone else has already done something similar. But it appears that there's no such tool made yet...
You are referring to ADO.Net Data Services. It basically creates an Entity Database Model and adds a REST frontend to the service using ASMX. There is a How To article availble from MSDN here on consuming the service using .Net. I have also done the same thing using the normally WebClient class in .Net in the past.
You can also look at the WCF REST Starter Kit if you want to roll your own based on Entity Framework. The starter kit also contains a handy new WebClient class that can be used to communicate with REST services.
Clarification
There is no prebuilt application client that I am aware off which will talk to these service, since they are pretty much accessing the data using Web Services. There is the Microsoft Smart Client Factory which is most likely the closest thing I have worked with.
I mentioned the above 2 options since they already have libraries in .Net that work with them directly, either as a referenced Web Service, or for the more adventurious, myself included, using the WebClient library or alternatively the new HTTPClient library in the WCF REST Starter kit.
I have used both, in Windows, Web, Silverlight and WCF. The latter being the easiest since they are focussed at REST.
We are currently investigating Prism which strongly leans to using this method when using WCF for front-end development.
Assumption
With regards to this question, you are making a generic assumption that wrapping ADO Entity Framework with a WCF service it will be generic. ADO.Net Data Services is the closest you will get, however the structure of the database will fundamently change the way you interact with it. Going a level higher in a "generic" way would be dangerous, as these 2 technologies, individually or together, are already as generic as possible.
In addition to Data Services (+1), consider RIA Services. It's like a domain-specific version of data services for Silverlight or WPF clients. Less flexible, but easier, than Data Services.
Ok, all these methods of getting data in a Silverlight control are confusing me.
I've looked at ADO.Net Data Services, Web Service and Silverlight-enabled WCF services.
I'm just not sure when one is appropriate to use over another. What pros/cons do each offer?
I've built a web app, and a Silverlight control. I will be adding one of those 3 options to my web application and consuming it from my Silverlight component.
From the silverlight perspective, WCF is heavily constrained anyway, so most of the usual benefits of WCF don't apply. However, it is still a fairly nice, consistent programming model.
WCF is primarily a SOAP stack, so it is very good at presenting data as rigid operations. ADO.NET Data Services is a REST stack, and allows very expressive queries to be performed dynamically over the wire.
I don't know how it is in Silverlight, but a regular ADO.NET Data Services proxy (the bit on your client app) has very rich support for both query and data changes back to the server. Note that applying changes requires either a: Entity Framework, or b: lots of work. But you should get query and update very cheaply with this approach.
With WCF, you get a much more controlled stack, so you will need to code all the distinct operations you want to be able to do. But this also means you have a known attack surface etc; it is much harder to exploit a locked down API like a fixed SOAP endpoint.
Re regular web-services (pre-WCF): only go down that route if you want to support very specific legacy callers.
I know this is old, but I just wanted to add my 2 cents.
I would highly recommend using WCF; and use the WCF Service Library project over the Silverlight-enabled web service. They are both essentially the same, but the Silverlight-enabled web service changes the binding to basic instead of ws*. It also adds an asp.net compatibility mode attribute.
WCF is usually faster: See "A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies" # http://msdn.microsoft.com/en-us/library/bb310550.aspx
WCF encapsulates asmx, wse, msmq, enterprise services, and remoting.
WCF services can be included and run within iis, windows forms, etc.
WCF isn't restricted to using HTTP, but with minimal configuration can also use tcp, named pipes etc.
complex data types are easier to expose and serialize.
WCF just scales really well. Plus, they can be used to incorporate workflows from WF.
There's probably not a wrong technology to use, but it seems as if Microsoft is going to be moving forward with WCF. Plus, it's just so much easier to write one code base that can be exposed so many different ways with just a few configuration changes to the WCF service.
I recommend not using the Silverlight-enabled web service, just because the programming structure is set up a little better with the WCF model, but this is probably a matter of opinion.
If you have to choose between a web service and a WCF service, my advice is to go with WCF. It's more modern and more powerful technology. As for ADO.Net Data Services - you can use that if all you need is to retrieve/commit some data from/to a database back on the server.