I have a client that is pushing for all data access to go over SOAP web services. No, I don't know why; I guess they like to keep their processors warm with all the XML building and parsing. Anyway... I have to move an existing web app programmed using a DataProvider on Oracle to WCF. I haven't written the web service yet. Are their any tools/frameworks/ideas to help create a DataProvider that uses a WCF proxy (or any SOAP client) for data access? Is this even possible?
Hopefully the ASP.NET site has some kind of "Data Access Layer", this will make your job much easier as it will have calls that are easy to proxy, e.g. bool SaveOrder( Order order ), Customer GetCustomerWithOrders( int customerID ) etc.
If instead the ASP.NET is making direct calls to the DataProvider (as I suspect might be the case) then you've got a big job on your hands, since it's a chatty process where you open a connection, do a few things that might require multiple calls to the database, then close it... whereas WCF works best as stateless calls. You can create sessions and try to proxy a DataProvider but I think that would actually make the app more complex and less stable.
I strongly recommend going back to the client and asking "Why do you want to convert to using SOAP and WCF, and what do you hope to gain?".
Related
I would like to have a client application and web application (or service, no UI) and I would like to connect to said web service from within my desktop application and to have two simultaneous network stream, one of them for uploading data and reading them on server and the other one for sending stuff to the client application.
I am not looking for a solution that uses anything more than that like WCF or anything, I just want a way to create connection between web server and my client application and exchange pure binary data. I would implement the protocol myself, I am not looking for any entities or encapsulation like WCF provides.
I don't even know what project type is the best choice here. I thought about empty ASP.NET application maybe that I'd upload on FTP but I have no idea what I should do next to make the application connectible to. I am not asking for complete solution of course, rather some articles that focus on how to make a plain and simple connection between server and client. I want server to be able to immediately update client and vice versa, that's why I am looking for a way to have stream.
Edit: I may as well say that the service is meant to be placed on ASP.NET hosting and I don't know how ports work on these, if there are any restrictions or anything.
"Web service" and "Network stream" are incompatible concepts. Web-services are (ideally) stateless and disconnected - so they work regardless of how the underlying network works. Messages are exchanged only from client-to-server and are encapsulated in HTTP request/response pairs. Hence "web service".
If you want to exchange "pure binary data" (as you put it) then you just need to work with sockets (or use .NET's TcpClient, which wraps up sockets in an easier-to-use API). ASP.NET would be inappropriate for this.
You can technically have an application that uses sockets that runs within an ASP.NET host process but this might not work depending on how security is set-up and it's also bound by the ASP.NET process lifecycle (so it is activated by IIS and can be shut-down or recycled at any time without warning).
You do not want to use ASP.NET Web Services for this (ASMX). That is a legacy technology, and should not be used for new development.
Why do you not want to use WCF? Do you believe it's too complicated? The thing about WCF is that it removes the complication of creating your own protocols.
Also, which version of .NET are you using? WCF get a lot easier to configure with .NET 4.0.
Here is simple duplex example using WCF.
Try it, check if performance you've got is enough, try to use alternative bindings ( like net.tcp). WCF is really neat tool to use. Once become more familiar with it you will love it.
Also check chapter on bindings in WCF from Learning WCF
Have a look at the MVC4 APIController. It works much like stock MVC except that methods return XML or JSON (or anything else you like).
Eg
/api/Users/Get
would could return something like
{
{"Username":"Bob", "Id":3},
{"Username":"Steve", "Id":4}
}
You can also return files and other streams by using special return types. You even get strongly typed, validated input through the use of models.
There's an example here which shows a full CRUD controller and sample AJAX calls from JS which you can replicate in your desktop app
I have created a C# application that I want to split into server and client side. The client side should have only a UI, and the server side should manage logic and database.
But, I'm not sure about something: my application should be used by many users at the same time. If I move my application to a server, will WCF create another instance of the application for every user that logs in or there's only one instance of the application for all users?
If the second scenario is true, then how do I create separate application instances for every user that want to use my service? I want to keep my application logic on the server, to make users share the same database, but also to make every single instance independent (so several users can use the WCF service with different data). Someting like PHP does: same code, new instance of code for every user, shared database.
By default, WCF is stateless and instanceless. This basically means that any call may be issued by any client, without any clients or calls knowing about each other.
As long as you have kept that in mind while designing the service, you're good to go. What problems do you expect to occur, given how your service is built at this moment?
The server-side (handled by WCF) will usually not hold any state at all: all method calls would be self-contained and fairly atomic. For example, GetUsers, AddOrder etc. So there's no 'instance' of the app, and in fact the WCF service does not know that it's a particular app using it.
This is on purpose: if you wanted to write a web app, or simple query tool, it could use those same methods on the WCF service without having to be an 'app', or create an instance of anything on the server.
WCF can have objects with a long lifetime, that are stateful, a bit like remoting, but if you're following the pattern of 99.9% of other designs with WCF, you'll be using WCF as a web service.
Edit: from the sounds of your comments, you need to do some seriously and potentially in-depth reading about client-server architectures and the use of WCF. Start from scratch with something small, then try to apply it to your current application.
I m planning to build another layer between application layer and database layer to reduce database access.
There are 200 hundred application servers and a single giant database server.
I wouldnt like 200 servers to query the db server. therefore planning to build another layer between and cache the data in this later, like cache farm. Servers in this layers will periodically query the db and cache the results in the service layer and clients will query the WCF servers.
I m not talking about distributed cache, which i already have.
I m not familiar with WCF, would it be a good option to implement for this purpose?
Would u recommend REST ? or web service?
WCF is the new standard for web (and other) services on the Microsoft stack, and it also suports building both SOAP-based as well as REST-based services.
It's also well suited for handling both internal (company-internal LAN/intranet - using fast and efficient TCP/IP communications) as well as outward-oriented services. It interfaces with Windows Azure and the cloud, if you need to support that. It interoperates with any SOAP or REST client, it's highly configurable, highly extensible, and all around useful and offers a unified programming model. It can interface with message queues, if you need that - all with the same programming experience.
Based on WCF, you can easily define your database models and expose those as REST-based OData feeds - you'll be putting your database out on the web in minutes (if you're adventurous and wish to do so .... but it's at least possible!).
So: YES! WCF is definitely the way to go!
As for resoures: there's the MSDN WCF Developer Center which has everything from beginner's tutorials to articles and sample code.
Also, check out the screen cast library up on MSDN for some really useful, 10-15 minute chunks of information on just about any topic related to WCF you might be interested in.
Standard SOAP web services are as easy as falling down when using WCF and you control both the server and client.
All you need to do on the server side is define your operations contracts and data contracts, and the clients will be able to build proxy classes for accessing your web services automatically.
There are some things you need to learn when defining your operation and data contracts, but once done, a client can VERY easily poke the service at design time, access the generated WSDL, and automatically generate a proxy class for accessing your new operations with their data contracts.
I would very rarely use REST as the primary interaction mechanism between application servers and database servers. If both ends of the interaction are controlled by you and live in the same data center and can be updated in sync then the extra work required to create a RESTful system would likely be wasted.
Personally, I would be more tempted to look at a messaging type system. Something like nServiceBus.
While the intention of my solution isn't necessary, I have run into a situation where I need to write a web service as an intermediate step in between the client and another web service.
[client] => [my web service] => [3rd party web service]
I am looking to see if anyone has any experience with this situation who could offer any advise or advise on any caveats that I can expect.
Note: I am developing using .NET and VS2008
No, its fine. In fact, its a great method to avoid a client from calling two web services when those calls are expensive (say from a phone). I created a solution once upon a time where my phone app would call my own web service, which would call another one, strip away a lot of the data and return the rest. You can get some pretty impressive perf increases if the main web service returns a lot of data.
The only catch may be authentication and that depends on a lot of variables and such. Good luck!
I've done it. It works fine. The only real concern is the same concern you'd have anyway - if the connection is broken between the two web serices, it's just another possible point of failure.
You can definitely do this. But, remember if you are transmitting any kind of sensitive data, you need SSL for the webservices.
On the negative performance implication sides, just keep in mind that any calls to this will get you two expensive HTTP connections instead of one expensive HTTP connection. Might be good to think about caching results in each layer if at all possible.
First I don't know the term of "Proxy Methods" are true way to describe what I need is but let me tell what I really want to know actually :
Suppose I have a class, named Proxy Class containing proxy methods
class ProxyMethods
{
public void CallHelloWorld();
}
actually this is a mirror, actual codes are storing in a web server. So how would this method call the real method that is locating in Web Server without using webservices ?
This way would secure my own code, if a refactoring software refactors the dll located in client's computer, then only thing it would show is that basic method signatures and some connection data which is used to connect the real classes located in Web Server.
So how would I accomplish it ?
Maybe Remoting ?
I'm not sure why you are trying to avoid web services. Performance concerns? Regardless, WCF is the way to go these days. Remoting is nearly totally obsolete. With WCF, it is a config change to go from traditional SOAP over HTTP web service transport to a binary, encrypted transport if you wish. There are so many options to tune the traffic, security, etc. to your needs.