I have been asked to replace a legacy "service" which processes XML requests (of an arbitrary format with no schema...) from multiple clients (Excel macros, C# apps) over Tibco EMS. I have no control over the clients.
I was hoping I could use WCF for this task but I don't think I can without a service contract. I have been toying with the idea of creating a WCF service and another console app service which would intercept and parse the existing XML requests and forward to the new WCF service (which new clients would use and existing clients could eventually migrate to).
However, this is adding complexity which could become a support and development headache. As such, I am tempted to build a console app based service which feels like a shame seeing as how much you get for free with WCF.
Has anyone else developed WCF apps for legacy non-REST, non-SOAP clients?
Related
Some time ago, I designed an application to an exisitng system. The application allows updating some app in PDA's. It is a kind of a remote updater. It uses web service.
Before I designed the application I had read some articles about WCF - technology. Then, I found a piece of information about comparision between SOAP protocol and REST architecture. Then I understood that REST is more useful for devices such as mobile or PDA's. Because of REST requires less data than SOAP. Obviously, I read more about REST that it uses HTTP methods and I know a lot about it.
As a result, I decided to use the REST architecture and everything was good. The application is still using.
Recently, I have changed my job. There is an application which uses a web service to sending data to PDA's. The web service uses SOAP protocol. I was very surprised when I have seen it first time. In my job, nobody can't tell me about it with some reasons.
Summarizing my story, I need to know that I am right that REST is a better option for a web service when we need to connect with PDA's or both option are correct. I don't need some description between SOAP vs. REST. I would like to receive a precision answer.
I want to make a IRC bot and got most of the code already, the only thing I don t know yet is or it is possible that I can host it in a WCF service. The problem I think is that it will be garbage collected ??? I want it to run in a WCF service so that I can manage it with my own WPF programm that will consume the WCF service. The bot must be a static object, since I only want the bot to be 1 time made. I don t want multiple instances. Also the bot must be 24/7 online.
Is this possible in a WCF service project ? or should I seperate the project ? in a console app/windows service and a seperate WCF project ?
Maxim
An IRC bot doesn't really fit the structure of web services, in my opinion: web services are generally sessionless functions that are in a request/response format, while an IRC bot is something that stays connected to a room and responds to some of the traffic while ignoring other.
A Windows service would probably be my first option. It fits well with what it needs to do: stay open at all times on a server, be able to talk to (messages to/from) the IRC channel as well as a database or other systems (e.g. if you keep a list of banned users in a DB).
I need multiple clients that talk to a WCF service. The WCF service also must be able to connect to any one of the clients also.
So - it sounds like the server and the clients need to have both a WCF server and client built into each one.
Is this correct or is there some way to do this?
I was looking at NetPeerTcpBinding, but that is obsolete. To be fair I'm not sure if that is a valid solution either.
Background:
I plan to have a Windows service installed on hundreds of machines in our network with a WCF service and a WCF client built in.
I will have one Windows service installed on a server with a WCF service and a client built in.
I will have a Windows Forms application
I will have a database
The clients on the network will connect to the service running on the server in order to insert some information on the database.
The user will use the Windows Forms application to connect to the Windows service on the server and this Windows service will connect to the relevant client on the factory floor (to allow remote browsing of files and folders).
Hence I believe the machines on the floor and the server both require a WCF cleint and service built in.
The reason people are recommending wsHttpDualBinding is because it is in itself a secure and interoperable binding that is designed for use with duplex service contracts that allows both services and clients to send and receive messages.
The type of communication mentioned 'duplex' has several variations. Half and Full are the simplest.
Half Duplex: Works like a walkie-talkie, one person may speak at any given time.
Full Duplex: Like a phone, any person may speak at any given time.
Each will introduce a benefit and a problem, they also provide ways to build this communication more effectively based upon your needs.
I'm slightly confused, but I'll attempt to clarify.
You have an assortment of approaches that may occur here, a Windows Communication Foundation (WCF) Service requires the following:
Address
Binding
Contract
Those are essentially the "ABC's" for WCF. The creation of those depicts a picture like this:
As you can see the Service will contain:
Host
Service
Client
The host houses the service which the client will consume so those service methods perform a desired task. An example representation:
As you see Client-1 is going through the Internet (HTTP, HTTPS, etc.) then will hit the Host, which will have the service perform those tasks.
Now Client-n is consuming the service locally, so it is talking over (TCP, etc.) as an example.
The easiest way to remember: One service can be consumed by however many clients require those methods to perform a task. You can create very complex models using a service-oriented architecture (SOA).
All WCF is, is a mean to connect your application to a host or
centralized location you may not have access to.
As you can see in the above image, the Client communicates through a Service to the Host. Which performs a series of task. WCF will talk over an array of protocols. Hopefully this will provide a better understanding of how WCF is structured.
There are a lot of tutorials and even post to get you started. Some excellent books such as "WCF Step by Step".
Essentially your looking for an asynchronous full duplex connection, or a synchronous full duplex service. As mentioned above, your task in essence is the point of a Service.
The question: How does this work best?
It will boil down to your design. There are limitations and structures that you will need to adhere to to truly optimize it for your goal.
Such obstacles may be:
Server Load
Communication Path
Security
Multiple Clients Altering UI / Same Data
Etc.
The list continues and continues. I'd really look up tutorials or a few books on WCF. Here are a few:
WCF Step by Step
WCF Multi-Tier Development
WCF Service Development
They will help you work with the service structure to adhere to your desired goal.
Remember the "ABCs" for the most success with WCF.
Use wsDualHttpBinding if you want your service communicate with your clients.
Read WS Dual HTTP.
You might want to try out creating a WCF service using netTcpBinding. It will work for your requirements. You can use the article How to: Use netTcpBinding with Windows Authentication and Transport Security in WCF Calling from Windows Forms as a start:
Also, there are many examples included within the WCF Samples package which you can use.
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.
I'm a complete newbie regarding network stuff, but here are two scenarios I'd like to accomplish:
I have a machine running a WCF service
Scenario 1: on the same machine, I have a C++ app that needs to get data from that service
Scenario 2: on a different machine, I have a C++ app that needs to get data from that service
The data that is exchanged will typically be around 1-10KB, but the method of transfer needs to also be able to handle bigger data exchanges (1-10MB).
What kind of configuration should I use on the WCF service to make this task as easy as possible?
If you want a service that can be accessed by non .NET code, the appropriate binding to use is basicHttpBinding. This way you will generate a service that adheres to the standard published web service protocol.
If you are writing a client in unmanaged C++, calling a web service is supported by ATL.
See http://msdn.microsoft.com/en-us/library/2k53kft2(VS.80).aspx for a walkthrough.