views:

118

answers:

3

(Yes, I'm disgruntled, irritated and argumentative, OK I'm venting a bit here at the top, but my actual question is objective, I promise <g>)

Venting

I've just spent the last 2 weeks touring many aspect of WCF and now ASP.NET web service. This was done via. the Get Error/Google Error/Fix Error (maybe)/Repeat cycle. After hours of that (mostly in the configuration section) I'm somewhat surprised that anyone even bothers using them. Enough Venting...

The Question

I need to have a client app call code on a web server over the internet. I want the Server side code to look something like this

interface I
{
  string GetFoo(int i);
  SomeType GetBar(OtherType ot);
}

[HostAsService<I>]
class Foo : I
{
    ....
}

and the client side to look something like this this

I i = new ServiceProxy<I>(new Uri("http://my.domain.com/some/path"));

the important bit is that the configuration for this is minimal and direct: no including the service name in 12 different places, no wizards generating code and web.config entries, no hidden URLs that I need to change when I switch from testing on my local machine to testing on out server. I just want it simple

Is there anything like that?

Note: I'd actually prefer a simpler, less flexible, fewer things to break model than a more complex, more flexible model. As long as I can stuff any serializable type down the pipe that's all the flexibility I need

note2: I'm not asking how to use WCF or ASMX services (if either can be made to work like I want/need, that's good, but I don't really care what's used at this point as long as it works)

A: 

Actually, WCF is flexible enough that you should be able to create such a thing yourself. I don't know where you'd specify the serialization to use if you don't use a config file, though. I also don't know how you'd convey your choice of serialization to the client once you changed it on the server.

Of course, without any configuration, you're stuck with defaults. I assume you want the default to be http or https, SOAP format, document/literal, no WS-* features, etc?

I'm a little concerned that you're using the term "ASP.NET Web Services". You're not using ASMX services, are you? Don't.

John Saunders
Serialization would be defined as normal on the types to be serialized the transport would be defined by the URL prefix, and the request encoding would be some arbitrary choice that no one should ever even have to known about.
BCS
As for ASMX, after spending a week trying to get all the WCF pieces working at the same time (every piece would work [the code locally, the web.cofig, the web server and a few others], but never all the pieces at the same time) I can get ASMX working on the server in about 10 minutes (but not locally Grrrrr).
BCS
If you care about this project, then don't use ASMX. It has little future left in it. It is unlikely to be enhanced, and even bug fixes are chancy. It is not a peer to WCF - it has been superseded by WCF.
John Saunders
At this point the feature requirement of "Works now" trumps "will continue working". That said, the plan is to encapsulate the whole thing so any non service implementation specific code just sees an interface (I also need a different non-network implementation) so in theory it shouldn't matter anyway.
BCS
+1  A: 

Here is a very simple example of a WCF service. It seems pretty close to what you want.

JP Alioto
Why The Heck isn't that what VS generates as the default template project?!?! :(
BCS
You're right, it should.
JP Alioto
+1  A: 

You can definitely do all that in a very basic WCF scenario - if you like, you can do all your setup and configuration in code as opposed to configuration.

You need on the server side:

1) a service contract IMyService that defines the function calls 2) a service implementation MyService that implements that interface 3) a service host that will host your service - this is the part where you'll have to define things like bindings (what protocol to use) and endpoint (what address to use)

You need on the client side:

1) access to the IMyService interface (put that into its own, separate interface assembly) 2) Create a ChannelFactory 3) Have the channel factory give you a channel to communicate with the service

This can all be done in code - no external config to speak of.

Aaron Skonnard of Pluralsight has had a great series of 5-15min. screen casts on how to create your WCF services - usually showing both how to do it in code, as well as how to do it with config. The show "Endpoint.TV" on Channel 9 was actually intermixed with workflow stuff, too - but you should be able to find the basic WCF screencasts in there, too. Check it out!

Marc

PS: If you're serious about learning about WCF (and I would definitely recommend that!), you should check out Michèle Leroux Bustamante's book Learning WCF - A Hands On Guide - highly recommended.

marc_s
I'd rather not do the setup in code (or in config files). I'd rather something that has *nothing to setup* aside from what interface to transport and the URL to point at.
BCS
At this point WCF/ASMX/whatever is supposed to be a slight easier way to do HTTP POST/GET's with .NET object. I'll keep that last link in mind in case I'm ever forced onto the MS web stack again.
BCS
You could also look into the REST capabilities of WCF - those are extensively covered in Aaron Skonnard's screen cast series as well.
marc_s
But I think a solution WITHOUT any config and/or setup in code just won't exist - heck, how do you know where to connect to, if you don't specify that ANYWHERE???
marc_s