C# WCF Web Service on localhost consumed by Java Client - c#

currently my WCF Service is using net.pipes to talk on local machine.
Now I want to consume the web service in java on the same machine.
Here I have some questions:
Which binding I have to use to talk on local machine with Java client?
I don't want to go over network and the client must be able to consume the web service.
Do you may have any articles or tipps how to start here? May some hints what I have to take care about?

BasicHttpBinding exposes a SOAP 1.1 wsdl which is probably the most interoperable between JAVA and .NET. If your calls are local then you won't go out to the network.
EDIT
WsHttpBinding supports SOAP 1.2 which is a larger, more complex specification and therefore more open to interpretation by different vendors. So while it may work fine, it will generally be less interoperable.
Specifically there may be differences in the way security is handled on either side (see here for a good explanation).

Related

REST vs. SOAP for remote connection with PDA's

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.

WCF client and server

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.

Difference between WebService and Remoting

I was comparing Web service with Remoting from performance and interoperatibility point of views
and have some doubts regarding it.
1) As Remoting support both TCP and HTTP channel, so is it when use TCP channel
It uses binary formatting and when HTTP, SOAP formatting
2) Can we use binary formating with HTTP protocol and XML/Soap formatting using TCP Protocol in Remoting
3) As Remoting supports XML/SOAP formatting which is universally accepted for any technology
and platform so it should provide interoperatibility between Server/client applications of
any technology/platform and if provide then what is use of web service.
As per my knowledge main advantage of Webservice over remoting is interoperatibility.
4) If I use Remoting with SOAP and HTTP, is it get bypassed by internet firewalls same way
as for web service or, still get restricted by firewalls.
5) Is any performance variation still exist if use remoting with SOAP formatting over
HTTP and webservice with SOAP formatting over Http.
6) Whether webservice support binary formatting and TCP Protocol as per my understanding
webservice only supports http prtocol but as per some programmers opinion in stack overflow
webservice is independent of transport protocol, so Is it like asp.net webservice only works on
http and web service developed in other technologies supports both TCP and HTTP.
Regards,
Arun Patil
If you use Remoting in HTTP mode, you WILL get past the firewalls.
While these two might seem they are doing the same thing, they are two different beasts. As an example, you can use interface types in Remoting, e.g. a service returning an interface, while this is not possible using ASMX Webservices (older stack) or WCF (only partially supported by KnownTypes), but on the other hand WCF supports multiple endpoints/bindings and better security and extensibility model than Remoting.
My advice would be if you are on a project already using Remoting, stick with it, otherwise it would not be a very wise choice to go with a technology that is, if not obsolete, won't get any new features so I'd suggest WCF for a green field project.

WCF Communication though named pipes with non .net App

I hear that WCF is the new standard for communication across the network and applications in .net. The idea seems to make sense as well, provide standard interfaces for programs to communicate.
Here is my situation, I have a .net app i want to communicate to a ruby application though pipes. On the .net side (server) I would like to use WCF while the ruby side (client) will be chewing gum and duct tape.
I assume both ends don't need to be WCF but what will be involved in making this work. Is there a standard protocol WCF expects incoming requests?
Using the named pipes binding for non WCF clients could be possible, but it wouldn't be easy. You'd need to send the messages in the correct format for WCF to consume.
See this first or last entry on WCF message framing for a hint at the complexity. It's not impossible, but is it worth the effort?
Recommended is the http transport + some type of text or markup encoding, like basicHttpBinding or webHttpBinding.
Depends on your bindings, you can make your WCF a webHttp binding and make it restful (easiest) and you just do gets and posts. Other bindings you will have to use SOAP headers and such to communicate with your WCF, I have not done this myself, but im sure theres info out there on how to do it for non .net applications.
You'll want to keep your contract as simple as possible (in terms of what types you expose). Though I have not tried this myself, I know that this type of functionality is supported (.Net to Java is a common usage) and relatively easy to do.
You don't mention which side (.Net or Ruby) will be the server, but I would expect that this will be much easier to do if you host the service in WCF and consume it from ruby. Going the other way around may be a bit more of a pain because mucking with the internals of WCF can be a bit of a pain.
What sort of "pipes" are you referring to? You cannot use the named pipes bindings with any code that's not .NET.
You'll probably be better off with one of the HTTP bindings, like webHttpBinding or basicHttpBinding.

What are the benefits of using WCF?

We currently just utilize soap webservices for all our communication but have been thinking about moving to WCF instead. What are the benefits of using it over an asmx service?
If we do go with a WCF service, can other languages still communicate with it? SOAP is standardized and all languages can interact with it.
Are there any really good examples of how to get started with WCF that show the benefits of it over soap?
EDIT
I just found this question which is quite helpful.
The Getting Started Tutorial is great.
There's a bit of a learning curve with WCF, but once you learn it it's no harder to implement than an asmx web services. One advantage is you can easily switch protocols and serialization from binary remoting all the way to web protocols. It's also easy to host either in IIS or out.
Other languages can communicate with the web protocols. Binary, not so much...
I just dug into the Getting Started Tutorial. It does a good job of showing the relative ease-of-use. From there, take a look at Hosting and more detailed Features.
WCF is not a replacement for SOAP, and indeed, SOAP can be used as the serialization format between endpoints for communication. SOAP the standard also doesn't really define what goes in the message body, so in the case of WCF-to-WCF communication, a SOAP envelope is used, but the content is binary, so there's your primary advantage, at least in terms of performance. Another advantage is that the programming model of WCF is, or at least is intended to be, much more straightforward; especially since it sounds like you're really just using Web Services to communicate internally. In this case, most of the work would be up front, configuring endpoints (though consuming asmx WSDLs is obviously very easy in .NET).
I'm no expert in WCF, but what I do know has been from .NET user group presentations by Juval Lowy (who wrote the O'Reilly WCF book), his site has a decent amount of information in the way of screencasts and samples in the Resources section, in addition to the Microsoft sites (have you checked Channel9?).
Based on this MSDN article that is linked in the question, WCF supports more than just SOAP. It has support for:
BasicHttpBinding
Interoperability with Web services and clients supporting the WS-BasicProfile 1.1 and Basic Security Profile 1.0.
WSHttpBinding
Interoperability with Web services and clients that support the WS-* protocols over HTTP.
WSDualHttpBinding
Duplex HTTP communication, by which the receiver of an initial message does not reply directly to the initial sender, but may transmit any number of responses over a period of time by using HTTP in conformity with WS-* protocols.
WSFederationBinding
HTTP communication, in which access to the resources of a service can be controlled based on credentials issued by an explicitly-identified credential provider.
NetTcpBinding
Secure, reliable, high-performance communication between WCF software entities across a network.
NetNamedPipeBinding
Secure, reliable, high-performance communication between WCF software entities on the same machine.
NetMsmqBinding
Communication between WCF software entities by using MSMQ.
MsmqIntegrationBinding
Communication between a WCF software entity and another software entity by using MSMQ.
NetPeerTcpBinding
Communication between WCF software entities by using Windows Peer-to-Peer Networking.

Categories

Resources