As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
This question was inspired by Jon Skeet's question here where he asked about people pain points with LINQ so I hope this question isn't out of place ...
Version 4 of WCF tackled, probably, one of the areas where many people struggled with WCF - namely configuration. However, from this tagged set of questions and other forums there are obviously other areas that people struggle with.
I've made a bunch of blog posts and screencasts in the past trying to focus on common issues (such as duplex, sessions, etc). I'm planning another set but want to focus on things that are causing people problems even with the changes in version 4.0.
Areas I see are things like
Instancing and Threading
Security
REST support
WCF and Silverlight
Large message processing / streaming
Configuration (still)
Serialization
And I'm sure there are more, so I'd like to get input and maybe we can make sure that the product team also get some feedback to the greatest pain points people have with WCF
I sometimes participate both here and on MSDN and after answering many questions my opinion is that the greatest pains people have are:
Configuration
Configuration is a pain even more then before. Simplified configuration makes a lot of things even worse because before this simplification if you made mistake in the configuration you got an exception. Today you will make typo in your service name (or you will forgot to add namespace) and your service will silently use another configuration.
Security
Security is a paint, it was a pain and it will be a pain.
Security itself is complicated and WCF is making this more blured because where programmers on other platforms use shared vocabulary based on real WS standards, WCF uses its own names.
Only subset of security standards implemented - one failure is missing UserName token profile with digested password directly in WCF.
When hosting services in IIS security features in services are completely shared with IIS and restricts settings for the whole site / virtual directory.
When hosting services in IIS basic authentication is handled in IIS - you must build custom module to handle it differently (but if you use self hosting you can use custom user name password validator in WCF directly - IIS should support that as well).
Bad support for generating security configuration when creating proxy from WSDL. Currently the best what WCF has is custom binding. Custom binding on client side is useful only when service is also WCF and uses custom binding. We need better support in security binding element to provide same configuration features as its counterpart in code. Then the WSDL importer should be able to use new binding element and create proxies for secured services. Once such importer is not able to import WSDL we will be sure that default WCF doesn't support security requirements expected by the service.
REST
Still a lot of people don't see difference between REST and SOAP and the most common mistake is adding service reference to REST service. Also problem of the REST is that it was added to unified protocol independent API but REST is heavy protocol dependent and is not message oriented. This will be hopefully improved in Web-API.
Protocols
It looks like new protocols or protocols versions are not added to WCF.
Extensibility
WCF has great extensibility unless you are trying to extend existing feature. If you decide to extend existing implementation you usually can't. For example to add mentioned UserName token profile with digested password you must do it completely from the scratch. You cannot extend existing user name implementation.
Edit: Last two are my personal pains.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We see REST web services as a way of "future-proofing" our business, among other things. I'm thinking through the tradeoffs of various ways of versioning our REST Web Services and I would like to find out what others have learned when it comes to versioning REST web services.
There are lots of good discussions on SO and other places about versioning web services, but most of them focus on whether to put the version number in the URL or the request header.
Versioning web services has multiple aspects to it. There is specifying the version in the web service call itself (URL or header). There is managing multiple versions of business logic in source code. There is building versioned web services. There are version control issues. And there is the matter of how to deprecate and drop obsolete versions.
Our partner who is writing our mobile clients wants to put the version in the URL so that is my approach (for now). In addition, the new versions of these web services may not be compatible with the old versions. For example there may be a different security implementation in different versions.
When it comes to versioned URLs two approaches are usually suggested - put the verion number in the URL or make it a parameter
context-root/service/rest/v0.1/restMethod/param1
context-root/service/rest/restMethod/param1?version=v0.1
The second method requires some controller logic to route the request to the right implementation, but that's not difficult. The choice between the two isn't difficult.
A third option is to put the version number in the context-root itself which means putting it in the .war filename prefix or in the deployment descriptor:
restarchive-v0.1/service/rest/restMethod/param1
This would mean deploying multiple archives for all versions currently supported.
I like having version numbers in filenames. It makes it easy to see what is deployed. The downside to this approach is that it requires a seperate build for each versioned archive, maybe with maven profiles.
Here's what the code for the first approach could look like. Each web method does it's own controller logic for all supported versions for that method. Business logic for each version can be handled a sensible way (i.e. put the version number in the package).
#ApplicationPath("/service/rest")
#Path("/{version}/")
public class RestService extends Application {
#GET
#Path("/user/{id}")
#Produces(MediaType.APPLICATION_JSON)
public User getUser(#PathParam("version") String version, #PathParam("id") int id) {
User user;
if (version.equals("v0.1")) {
// call v0.1 code to get the User
}
else if (version.equals("v0.2")) {
// call v0.2 code to get the User
}
else {
throw new WebApplicationException(Response.Status.NOT_FOUND);
}
return user;
}
}
My first implementation of this used multiple subclasses of javax.ws.rs.core.Application in different packages with the version number in the package. That should work, but the JBoss RESTeasy implementation doesn't allow multiple subclasses of Application in one .war. That apparently is a violation of the JAX-RS 1.1 specification, but it's a limitation you'll have to live with if you use JBoss or RESTeasy.
I'm inclined to use the first approach with an implementation similar to the one above. Since I'm trying to minimize problems in the future I would like to hear what others have learned through experience with the various aspects of version web services.
Is this a sound approach, or will it lead to problems that I haven't mentioned here?
This topic was brought up at JavaOne, and there is no right answer.
The guy giving the presentation that touched on this said his preference was to keep the version in the header and avoid putting it in the URL or as a query param.
Personally, we version the files themselves. We have to deploy separately versioned builds anyways, so its not much extra hassle. We just pull the version # from the Manifest and append ?{version} to the files.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are the pros and cons of using a rest service vs a wcf service?
I am wondering which type to use and I was interested to find some sort of comparision.
Rest is a way of doing communication over the internet. It is a very basic process of picking addresses to serve as method locations and returning HTML standard data (javascript, css, html of course).
WCF is a .net library used to have two programs talk to each other using SOAP. Which consists of two very familiar programs trading class info.
Seeing as Rest is a process, and WCF is a class library, a better question might be "Rest vs Soap".
The bottom line is, if you need two apps to talk, you might want to use WCF. Even if the apps are not both written in .net. However if you need information to be accessed by web tech(usualy javascript access is done this way) you'll want to use Rest.
Just a quick side note though, WCF does Rest well too, so you realy can't go wrong there.
You're asking a question about apples and oranges. REST is pattern used in creating web services. I'm not an expert on it, but you can find plenty of details on Wikipedia. WCF is a Microsoft technology for creating web services (primarily using SOAP, although it's so configurable that you can do REST on it as well - see ASP.Net WebAPI).
Pros for WCF:
Very configurable - If you can imagine it, WCF can probably do it.
Simple to use if you're sticking to the Microsoft stack. Visual Studio does 90% of the work for you.
Cons for WCF:
Very configurable - It can be a bit of a pain to get it do exactly what you want sometimes, especially if you're new to it.
There can be some problems communicating between different technology stacks. I've heard of Java services curling up and dying when pointed at a WCF service. As far as I've heard, this is a problem with the Java libraries, not WCF, but who knows for sure.
That's all that comes to mind right now, but hopefully that gives a you a decent impression on WCF.
If you are absolutely sure that HTTP is the protocol you want to use and you want to embrace it as an "Application" protocol, not just a "Transport" protocol then something like ASP.NET Web API.
If you building a service for your servers in your datacenter to talk to each other then seriously consider WCF.
Whether to do REST is a completely different question. Will this service last for many years? Will it have many different clients? Will some of those clients be out of your control? If you answered yes, then it may be worth investigating what benefits the REST constraints can bring.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Could you tell me the open source alternatives to WCF??
I'm a newbie and just started using WCF. I wanted to know about the alternatives that are open source too.
Also, what makes them better options/not so good compared to WCF.
Thanks,
Thothathri
There are open source projects for REST services - for example Open Rasta Perhaps you will also find some open source projects for basic SOAP services but I doubt that there is an open source project implementing all WS-* related stuff implemented in WCF. WS-* protocols are mostly implemented only in API from big companies - MS, IBM, Oracle, SAP, etc. Reasons are:
Complexity - implementing WS-* protocols means diving deep into tons of specifications. You must also implement them very carefully to be really interoperable and to do not reduce performance too much.
Support - WS-* protocols are usually used in B2B solutions where enterprises demands some guarantees and support.
Costs - developing such API takes really long time.
Even WCF implements only subset of WS-* protocols. But WCF is highly extensible so anybody can try to implement some of these missing protocols himself.
WCF doesn't states only for REST and SOAP services. It is also replacement of .NET Remoting and Enterprise services from older .NET versions. You will not find a .NET API which will also offer all this functionality.
I also highly recommend checking out ServiceStack, it's a config-free web service framework I started that lets you easily and rapidly develop web services with very little friction.
It provides an expressive friction-less environment as you're able to develop web services by using you're own POCO C# DTO's which also encourages best-practices web service development since you're easily able to create more batch-full, coarse-grained APIs.
It's aims to be more productive by closely fusing C# with HTTP where all C# objects returned get automatically serialized to the requested format with (XML, JSON, JSV, CSV, SOAP 1.1/1.2, HTML) supported out-of-the-box. C# Exceptions also get automatically serialized for you making the tedious things effortless.
One of the major benefits is not needing to be concerned with external formats and endpoints (which are taken care by the framework) and you're left with developing your logic in a clean-room, auto-wired and highly testable, DDD-like IService class.
You could use RestCake if you're trying to create RESTful services.
Mono project has an ongoing effort for WCF hosted in Github. As you know, System.ServiceModel is the main engine for WCF. You can find Mono implementations of these namespaces under /mono/mcs/class/System.ServiceModel.* . You can find project related updates and relevant contribution information here
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am planning on putting up a web service, or some other service exposed over the internet. I would like to create an API for applications to interact with this service. I would like the API to be usable in different languages, such as Java, C++, C#, or PHP. How can I maintain one code base for my API, but distribute nice packaged binaries for all these languages? Also, I may want to consider this could be cross platform as well.
Update 1
I'm early days on Web Services, but I
think one of the key points is that
lots of tooling supports the
implementation of clients based on the
description of the service like WDSL.
I've not delivered any client-side
software with anything I've done, I
expect any user to be able to build
their own clients suited to their
needs. --Brabster's Answer
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
Update 2
As far as expecting the client that is
using your API to do anything, you
can't! There is nothing you will be
able to do to ensure that the consumer
of the API will do anything right.
That's why robust error handling is so
important. You must check and double
check any and everything that comes
from the client. You must always be
suspicious of it, and even assume that
it is malicious. There really is no
good way around that fact. --Ryan Guill's Answer
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
Update 3
I have accepted Ryan Guill's answer. I think the general idea is that I need to expose a network service of some sort, with the lowest barrier to the client. That way anyone can connect. Then just have all my code run on the server. That seems to be accepted as the only want to really achieve the platform and language independence I am after.
Thanks for all the input.
I would use a REST API, similar to the way Flickr's API works: http://flickr.com/services/api/
It is fairly simple to create and maintain, the biggest downsides are that it takes a lot of documentation (but pretty much any way you do an API will have this issue) and that robust error handling is a must.
But in my opinion, it's the best way to create an API that is the closest to cross platform/cross language.
More information here: http://www.xfront.com/REST-Web-Services.html
Update: The submitter added the following to the post:
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
I personally do not like using SOAP (using a WSDL). There is a lot of inherent overhead to using SOAP, both on the server and the client. I think that is why you see more and more public API's being written using REST. It really lowers the barrier to entry to the lowest common denominator, allowing anything that can use basic HTTP (GET and POST (also PUT and DELETE for the "proper" way of doing it)) to use the API.
Some more examples of public API's written using REST: twitter, vimeo, Google
As far as expecting the client that is using your API to do anything, you can't! There is nothing you will be able to do to ensure that the consumer of the API will do anything right. That's why robust error handling is so important. You must check and double check any and everything that comes from the client. You must always be suspicious of it, and even assume that it is malicious. There really is no good way around that fact.
Update 2: the submitter added the following to the post:
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
You can certainly do this, but that is only going to work for .NET languages, meaning that your cross-platform and cross-language benefits are out the window. And still, in the end, are you really preventing anything? The developer is going to either use your remote API, or your local DLL or Assembly. Either way, he is going to have to know how to use it and use it right, otherwise you are going to throw an error. All you are really doing is changing where the errors get thrown from. Which may be important to you (if so, mention why) but really isn't changing anything in the equation.
But you are somewhat correct in saying REST is kind of like web-services without the SOAP. Technically REST is web-services too, its just that web-services have come to generally mean SOAP. It really is a different way of achieving the same thing. The biggest differences are though that it takes more programming and thought on your side (and potentially more programming on the client side) but you trade that for robustness, less overhead in both the consumer and the server, and the widest possible audience for the API. It really is the lowest common denominator.
I'm early days on Web Services, but I think one of the key points is that lots of tooling supports the implementation of clients based on the description of the service like WDSL.
I've not delivered any client-side software with anything I've done, I expect any user to be able to build their own clients suited to their needs.
If you check out the flickr API as suggested by one of your other answers, I don't think they supply client side code, other people have built and contributed client side stuff.
I suggest writing the API in the Haxe programming language so that the source code can be directly translated to all the programming languages you mentioned. The Haxe programming language can be translated (or "trans-compiled") to all of the programming languages that you mentioned in the original post, as well as a few others.
Simple answer, no.
Complex answer: create an API and compile it to a COM dll. Then, just build the wrapper code for the languages that can't handle that.
Simple answer #2, make the original service so trivial, or so universally acceptable, as to not require an API (I usually implemented this through server-side database polling. Ugly but any language that can access a database can utilize the program).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I understand the value of the three-part service/host/client model offered by WCF. But is it just me or does it seem like WCF took something pretty direct and straightforward (the ASMX model) and made a mess out of it?
Is there an alternative to using SvcUtil's command line step back in time to generate the proxy? With ASMX services a test harness was automatically provided; is there a good alternative today with WCF?
I appreciate that the WS* stuff is more tightly integrated with WCF and hope to find some payoff for WCF there, but geeze, otherwise I'm perplexed.
Also, the state of books available for WCF is abysmal at best. Juval Lowy, a superb author, has written a good O'Reilly reference book "Programming WCF Services" but it doesn't do that much (for me anyway) for learning now to use WCF. That book's precursor (and a little better organized, but not much, as a tutorial) is Michele Leroux Bustamante's Learning WCF. It has good spots but is outdated in place and its corresponding Web site is gone.
Do you have good WCF learning references besides just continuing to Google the bejebus out of things?
Okay, here we go. First, Michele Leroux Bustamante's book has been updated for VS2008. The website for the book is not gone. It's up right now, and it has tons of great WCF info. On that website she provides updated code compatible with VS2008 for all the examples in her book. If you order from Amazon, you will get the reprint which is updated.
WCF is not only a replacement for ASMX. Sure it can (and does quite well) replace ASMX, but the real benefit is that it allows your services to be self-hosted. Most of the functionality from WSE has been baked in from the start. The framework is highly configurable, and the ability to serve multiple endpoints over multiple protocols is amazing, IMO.
While you can still generate proxy classes from the "Add Service Reference" option, it's not necessary. All you really have to do is copy your ServiceContract interface and tell your code where to find the endpoint for the service, and that's it. You can call methods from the service with very little code. Using this method, you have complete control over the implementation. Regardless of the method you choose to generate a proxy class, Michele shows both and uses both in her excellent series of webcasts on the subject.
Michele has tons of great material out there, and I recommend you check out her website(s). Here's some links that were incredibly helpful for me as I was learning WCF. I hope that you'll come to realize how strong WCF really is, and how easy it is to implement. The learning curve is a little bit steep, but the rewards for your time investment are well worth it:
Michele's webcasts: http://www.dasblonde.net/2007/06/24/WCFWebcastSeries.aspx
Michele's book website (alive and updated for VS2008): http://www.thatindigogirl.com/
I recommend you watch at least 1 of Michele's webcasts. She is a very effective presenter, and she's obviously incredibly knowledgeable when it comes to WCF. She does a great job of demystifying the inner workings of WCF from the ground up.
I typically use Google to find my WCF answers and commonly find myself on the following blogs:
Blogs with valuable WCF articles
http://blogs.msdn.com/drnick/default.aspx
http://blogs.msdn.com/wenlong/default.aspx
http://blogs.thinktecture.com/buddhike/
http://www.dasblonde.net/default.aspx
Other valuable articles I've found
http://blogs.conchango.com/pauloreichert/archive/2007/02/22/WCF-Reliable-Sessions-Puzzle.aspx
http://blogs.msdn.com/salvapatuel/archive/2007/04/25/why-using-is-bad-for-your-wcf-service-host.aspx
I'm having a hardtime to see when I should or would use WCF. Why? Because I put productivity and simplicity on top of my list. Why was the ASMX model so succesful, because it worked, and you get it to work fast. And with VS 2005 and .NET 2.0 wsdl.exe was spitting out pretty nice and compliant services.
In real life you should have very few communication protocols in your architecture. This keeps it simple an maintainable. If you need to acces to legacy systems, write specific adapters for them so they can play along in the nice shiny and beautiful SOA world.
WCF is much more powerful than ASMX and it extends it in several ways. ASMX is limited to only HTTP, whereas WCF can use several protocols for its communication (granted, HTTP is still the way most people will use it, at least for services that need to be interoperable). WCF is also easier to extend. At least, it is possible to extend it in ways that ASMX cannot be extended. "Easy" may be stretching it. =)
The added functionality offered by WCF far outweighs the complexity it adds, in my opinion. I also feel that the programming model is easier. DataContracts are much nicer than having to serialize using XML serialization with public properties for everything, for example. It's also much more declarative in nature, which is also nice.
Wait.... did you ever use .NET Remoting, cause thats the real thing its replacing. .NET Remoting is pretty complicated itself. I find WCF easier and better laid out.
I don't see it mentioned often enough, but you can still implement fairly simple services with WCF, very similar to ASMX services. For example:
[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class SimpleService
{
[OperationContract]
public string HelloWorld()
{
return "Hello World";
}
}
You still have to register the end point in your web.config, but that's not so bad.
Eliminating the verbosity of the separated data, service, and operation contracts goes a long way toward making WCF more manageable for me.
VS2008 includes the "Add Service Reference" context menu item which will create the proxy for you behind the scenes.
As was mentioned previously, WCF is not intended solely as a replacement for the ASMX web service types, but to provide a consistent, secure and scalable methodology for all interoperable services, whether it is over HTTP, tcp, named pipes or MSMQ transports.
I will confess that I do have other issues with WCF (e.g. re-writing method signatures when exposing a service over basicHTTP - see here, but overall I think it is a definite imrovement
If you're using VS2008 and create a WCF project then you automatically get a test harness when you hit run/debug and you can add a reference without having to use svcutil.
My initial thoughts of WCF were exactly the same! Here are some solutions:
Program your own proxy/client layer utilising generics (see classes ClientBase, Binding). I've found this easy to get working, but hard to perfect.
Use a third party implementation of 1 (SoftwareIsHardwork is my current favourite)
WCF is a replacement for all earlier web service technologies from Microsoft. It also does a lot more than what is traditionally considered as "web services".
WCF "web services" are part of a much broader spectrum of remote communication enabled through WCF. You will get a much higher degree of flexibility and portability doing things in WCF than through traditional ASMX because WCF is designed, from the ground up, to summarize all of the different distributed programming infrastructures offered by Microsoft. An endpoint in WCF can be communicated with just as easily over SOAP/XML as it can over TCP/binary and to change this medium is simply a configuration file mod. In theory, this reduces the amount of new code needed when porting or changing business needs, targets, etc.
ASMX is older than WCF, and anything ASMX can do so can WCF (and more). Basically you can see WCF as trying to logically group together all the different ways of getting two apps to communicate in the world of Microsoft; ASMX was just one of these many ways and so is now grouped under the WCF umbrella of capabilities.
Web Services can be accessed only over HTTP & it works in stateless environment, where WCF is flexible because its services can be hosted in different types of applications. Common scenarios for hosting WCF services are IIS,WAS, Self-hosting, Managed Windows Service.
The major difference is that Web Services Use XmlSerializer. But WCF Uses DataContractSerializer which is better in Performance as compared to XmlSerializer.
In what scenarios must WCF be used
A secure service to process business transactions. A service that
supplies current data to others, such as a traffic report or other
monitoring service. A chat service that allows two people to
communicate or exchange data in real time. A dashboard application
that polls one or more services for data and presents it in a logical
presentation. Exposing a workflow implemented using Windows Workflow
Foundation as a WCF service. A Silverlight application to poll a
service for the latest data feeds.
Features of WCF
Service Orientation
Interoperability
Multiple Message Patterns
Service Metadata
Data Contracts
Security
Multiple Transports and Encodings
Reliable and Queued Messages
Durable Messages
Transactions
AJAX and REST Support
Extensibility
source: main source of text
MSDN? I usually do pretty well with the Library reference itself, and I usually expect to find valuable articles there.
In terms of what it offers, I think the answer is compatibility. The ASMX services were pretty Microsofty. Not to say that they didn't try to be compatible with other consumers; but the model wasn't made to fit much besides ASP.NET web pages and some other custom Microsoft consumers. Whereas WCF, because of its architecture, allows your service to have very open-standard--based endpoints, e.g. REST, JSON, etc. in addition to the usual SOAP. Other people will probably have a much easier time consuming your WCF service than your ASMX one.
(This is all basically inferred from comparative MSDN reading, so someone who knows more should feel free to correct me.)
WCF should not be thought of as a replacement for ASMX. Judging at how it is positioned and how it is being used internally by Microsoft, it is really a fundamental architecture piece that is used for any type of cross-boundary communication.
I believe that WCF really advances ASMX web services implementation in many ways. First of all it provides a very nice layered object model that helps hide the intrinsic complexity of distributed applications.
Secondly you can have more than request-replay messaging patterns, including asynchronous notifications from server to client (impossible with pure HTTP), and thirdly abstracting away the underlying transport protocol from XML messaging and thus elegantly supporting HTTP, HTTPS, TCP and other. Backward compatibility with "1-st generation" web services is also a plus.
WCF uses XML standard as the internal representation format. This could be perceived as advantage or disadvantage, especially with the growing popularity "fat-free alternatives to XML" like JSON.
The difficult things I find with WCF is managing the configurations for clients and servers, and troubleshooting the not so nice faulted state exceptions.
It would be great if anyone had any shortcuts or tips for those.
I find that is a pain; in that I have .NET at both ends, have the same "contract" dlls loaded at both ends etc. But then I have to mess about with a lot of details like "KnownType" attributes.
WCF also defaults to only letting 1 or 2 clients connect to a service until you change lots of configuration. Changing the config from code is not easy, shipping lots of comfig files is not an option, as it is too hard to merge our changes into any changes a customer may have made at the time of an upgrade (also we don't want customers playing with WCF settings!)
.NET remoting tended to just work most of the time.
I think trying to pretend that .NET to .NET object based communications is the same as sending bit so of Text (xml) to an unknown system, was a step too far.
(The few times we have used WCF to talk to a Java system, we found that the XSD that the java system gave out did not match what XML it wanted anyway, so had to hand-code a lot of the XML mappings.)