I have one ServiceStack application with one class named Performance in this application.
Now, I have another application which is used by my end user. This is a console application, downloaded by end user and run as a background task.
I want to POST the performance data from that application to my REST web service and store it in a database.
For that I need to run this in my client application, which posts the performance data to my ServieStack application in JSON format:
JsonServiceClient client = new JsonServiceClient("http://localhost/RestIntro");
var res = client.Post<Performance>("/Performance", c);
I don't have Performance class in my client application. I don't want the client to have the class so that I can update all clients if I need to make a change.
I want to know, how can I get the Performance class or its DLL in to my client application dynamically? So when the client runs it will have the class in order to make the post to the web service.
I recommend that you keep the DTOs of your ServiceStack web services separate in a dependency-free project as this is what represents the contract or API of your services. If it's in its own assembly than you can easily share it with any of your clients or unit tests, etc.
If you don't like the idea of copying a dll around (even though its less work/friction), you can generate your own DTOs from the xsds on the /metadata page, see this question:
How can i convert XSD file to C# Class
What you are talking about is actually available by using a SOAP service. Or, you need to create a "performance" class on the client and deserialize the JSON result to that class.
Related
I'll try to explain the situation in the best way possible, I hope someone out there can guide me a bit.
We have a working .NET MVC 4 app where we've added a service reference to consume a WCF external service.
We've created several classes and methods to translate our data model to service's one, so we can call it's different methods from within our app using our data model.
Now we have a new requisite: to add our own service, which can be accessed from outside our environment, and who has to replicate some of the methods of the original service.
The idea is that users will post info to our environment through our service, we'll apply several treatments to the info, and then post it to the original service.
So my question here is: How do I create and attach the new service to my MVC app so I can get advantage of the classes and methods that are already developed and the data model of the original service?
I have a web site and would like to expose certain functionalities using WCF.
Before deciding which type of WCF project I need to use I wanted to compare the differences between WCF Class library and WCF application. I know this question has been asked many times and answered many times and the answers are usually about different hosting options each one offers but I wanted to try and see the differences, so this is what I tried:
Step 1 - In a same solution, I have created a WCF Service library project and created Client console app project, set the console app as a startup project, referenced the service library project from the client project
and in the client console app I could instantiate the service and can consume the service methods. I didn't even add a service reference to the client project.
Step 2 - In a same solution, I have created a WCF Service application project and created Client console app project, set the console app as a startup project, referenced the service application project from the client project
and in the client console app I could instantiate the service and can consume the service methods. I didn't even add a service reference to the client project.
On both steps after compiling the solutions I was able to copy the client app's exe and the service dll's to a different location and still be able to run the clients.
Based on this little excercie I am confused about the hosting part. It seems wether I use WCF Class library or WCF application type I get the same result.
This is just like using multiple projects in a solution, you reference one from another and use the methods, there must be something I am missing which highlights the differences between the two and highlights the benefits of using WCF, also in the past I remember I had to add a service reference to the clients apps in order to consume the service, why is this not the case here?
Thanks
1) Running a wcf service application allows you to provide communication into a single application, where you have a single instance of a thing you want to provide access to. Maybe this is a game, or a chat room without an external state engine or datastore. This is useful for providing diagnostic information about an application you might have written for example. I used this to provide external control for an industrial robot that I wanted to provide remote control access for.
That is to say, that you write an application, it has a function. You want to expose part of that functionality to remote applications. You do this by adding a WCF endpoint to your existing application, so your application itself is controlling the WCF hosting elements, lifecycle of the endpoint etc.
2) Running a WCF Service is for when you've got an external data store, or your service is stateless. A translation service, lookup service and web page requests fall into this category.
With a service class, you're saying here is this service, this thing that provides a function. It isn't tied to the lifecycle of another application or process and is typically hosted by IIS. IIS manages when the class is loaded and run based on the requests that come into it. These services have no internal persistence and rely on an external datastore, or are, by nature, stateless (think of a postcode lookup, or a calculator service)
It sounds like you're actually adding the projects as references, rather than connecting to them as services. That is to say, that the consuming application is actually loading the service as an assembly (in the same application/ memory space) rather than as a separate application/ service that your application then uses WCF to communicate with.
The WCF Service Application template can be used to create WCF services with a hosting website created within the project
The WCF Service Library template can be used to create WCF services that are hosted by the WCF Service Host, and these can be tested using the WCF service Test Client.
the biggest advantage of using a standalone library (apart from decoupling the logic) is that you can easily migrate your service, i.e. host it in another application or another type of application. E.g., let's say you're hosting your service using IIS - you can easily move your service to a standalone application, etc.
I'm building an application with a Silverlight frontend that communicates with a backend service via WCF. My service has an interface that handles all of the core communication with the frontend.
The backend can be extended with various plugins and I plan on loading custom silverlight modules for configuring these plugins with prism. The problem is, these plugins will add additional functions that aren't part of the base WCF interface. I'd like to maintain a single endpoint for all my communication (i.e. not requiring additional router configuration).
I'm looking for some ideas on how to approach this implementation. My "best" thought at the moment is to have a function in my core interface that accepts a function name and a list of parameters, and using reflection to find the function to call in the specific plugin, I'm not a fan of this for many reasons.
What are your recommendations for building an extensible WCF interface on a single endpoint?
Thanks
I can think of two ways this is typically handled:
XML contracts - basically, your service becomes nothing more than an XML parameter, with an XML return value. Then, you can either parse or serialize/deserialize the command going between the client and the server. Because your contract only exposes the single XML, what you do "inside" is up to you. You can do things like transmit schemas for the new methods to validate calls constructed on the client, etc.
RESTful service - this is another easy way to do it. Because the REST contract is the URL, adding a new extension is as simple as providing a new URL format. You could communicate via a formatter to the client how to invoke new calls for the extension methods and manage these as you build out the application.
Realistically, however, I doubt your font-end is going to be able to handle all edge cases and dynamically build new screens and validations as you extend the server side. In this case, a better approach in my opinion would be to construct the Silverlight application as a module application using MEF. When you have an extension on the server, you can simply provide an extension XAP for the client. You can have the server enumerate XAP files in a directory for plugins and send these to the Silverlight application, so when a new one becomes available it can dynamically load these. The XAP would contain the code to wire to the new WCF contracts for the extended functionality.
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.
I have the following class in Class Library: Artist, which is a POCO
Now I have a method in a web-service (which has a reference to the mentioned-above library) with a signature like this:
[WebMethod]
public int Artist_AddArtist(Artist a) {
//
}
When I try to consume this service from an application (that also has a reference to the mentioned-above Class library), the expected parameter of the Artist_AddArtist method is not Artist, but a new type of Artist that is being generated in Reference.cs which is a partial class that is auto-generated.
Thus since in my application I use, supposedly the same Artist class from the library and now the Web Service method expects this new auto generated type, I cannot pass an instance of it to the web-service.
How can I fix this issue?
Maybe switching to WCF services is an option for you. As far as I remember, with a WCF service, you can reuse the same types on ther server and client side.
This article explains how to migrate an ASMX web service to a WCF service.
You cannot, and should not, fix the problem.
Some others will tell you to do things like edit the generated file, but that's not a good practice (as the changes will go away as soon as the Web Reference is updated).
What you're seeing is by design. See Basics: How Web Services Work.
Briefly, when you use "Add Web Reference", Visual Studio downloads the WSDL file from the service, and uses the XML Schemas from the WSDL to create some proxy classes to represent the XML described by the schema. It also creates a proxy class for the service itself, having methods for each operation in the service.
The proxy data classes can serialize to the XML that the service is expecting to receive, and can be deserialized back from the XML that the server sends in reply.
One way to think of it is that you only have this problem because both client and service are .NET. If your client were written in Java, then you wouldn't be thinking of sharing classes.
Note that WCF can do this, if necessary. It introduces a dependency between the client and service (they both have to use compatible versions of the assembly containing the classes), but when you need to do it, the option is there. It's useful when there is behavior in these classes that must be used both by the client and by the service.