When developing an application wich will be used inside an intranet do you think Silverlight and WCF is a good solution ?
Whould you use WCF Services or WCF Web Services to expose your model to the client ?
When consuming a WCF Service the proxies will be generated under a reference and you can only have 1 service reference per service, How can I have the application domain model created under the same service reference ?
Thanks.
A. Lampard.
Not yet. I had a difficult time getting WCF configured, and Silverlight 2 beta was not well documented.
Silverlight is out of Beta now, and compatibility with WPF has improved. If your skills are generally in .NET and you want a rich web application then Silverlight ought to be a no-brainer, especially on an intranet where you can reasonably guarantee everyone has Silverlight installed. Plus, it runs fine on Macs.
For services, WCF works with Silverlight and there are numerous examples of how they work together. Here's a video from the official site on that very subject:
http://silverlight.net/learn/learnvideo.aspx?video=47177
"Not sure if I understand your second question...not sure why would you want more than 1 reference per service...?"
When you have, for example, a ProductService wich uses the classes Product and Family, if you create the proxies for this service you'll get: ServiceReference1.Family and ServiceReference1.Product. Now supose you create the FamilyService, when consuming this service you'll get the Family proxy created again, but under ServiceReference2 !
Your questions is way too broad. It's really hard to answer these kinds of questions, since, really, "any" technology is good for "any" solution. Otherwise everybody would just use one!
What's your application supposed to do, how soon you need to get it done, is there any existing investment in the same or other technologies...etc.?
Having said that, to answer your question: yes.
Not sure if I understand your second question... not sure why would you want more than one reference per service...?
Related
I need to configure end-points on my Silverlight client for both a WCF and a RIA Services endpoint. Is this possible? If so, what are the gotchas?
I think the one thing I could say is that there is some overlapping between both anyway, in fact RIA is already using WCF but just creates another layer to work easier with SOAP and JSON (good because silverlight runs in the client and those data structures are natural for small transferences), as long as your services are basic enough you might work with any of them.
But the overall need for RIA was that Silverlight cannot make 'intrusive' tasks like updating a database, so there was a need to create a lightweight service infrastructure to help you make those tasks.
If you ever think that a RIA service contract might also be useful for other clients, maybe you will gain something by porting it to the normal WCF platform which will give you a lot more flexibility and reliability.
I hope this adds something to the discussion,
I finally got my client working with both endpoints. I troubles I had had nothing to do with there being two types of endpoints, though I thought they did. If anyone has anything to add about gotchas, I'll accept their answer, otherwise I think the answer is a resounding yes. I figured it was since RIA Services is fundamentally WCF anyway.
What is the difference between WCF Services and Web Services in .netWhen should I use WCF and when to use Web Services.Is REST and WCF service the same? Thanks
Web Service is an abstract term encompassing a large variety of data providers for distributed systems. Perhaps you are referring to ASMX web services, which can still be found in the wild but aren't really widely used in new development these days.
WCF Service is Microsoft's implementation of SOAP. There are others implementations or you could roll your own (not recommended).
SOAP is a kind of stateful, session-based, message-based web service. It's good if your service is designed as a set of complex actions.
REST is a stateless, sessionless, resource-based web service. It's good if your service is designed to access data and perform simple CRUD operations on it. SOAP and REST are mutually exclusive. A service cannot be both. There are ways to manipulate vanilla WCF to make is RESTful but these techniques are becoming deprecated. If you want to implement a RESTful web service there are two main choices in the Microsoft world: WCF Data Services and ASP.NET Web API.
REST is an architecture
WCF is a API in .NET Framework to build connected service oriented application.
In olden days a functionality developed as Web Service was accessible via internet and the same to be available on local network was available via Remoting.
Using WCF we don't need to develop different code for it to be accessible over internet and on local network. Just configuring it with bindings would be enough.
That is a very wide question...I am going to just give a brief high-level answer and suggest that you do some more searching as there are is already a lot written on each subject. But, hopefully this should give you a push in the right direction.
First, typically when people refer to WCF Services and Web Services, they are referring to the newer WCF conventions that make service calls fairly generic (they can be SOAP, REST, etc) and the old .asmx SOAP method of Web Services. So, along these lines, I would suggest looking more into WCF and SOAP/.ASMX for the difference of WCF and older Web Services.
As to WCF and REST, they are not the same. REST is more of an architecture, whereas WCF is a framework. As I already mentioned, WCF can be used to make SOAP calls or REST calls. I am not sure I can add much more without going into greater detail.
I will see if I can find some good articles on REST and WCF a little later, though. Personally, I do not see a reason to even pursue very far into the older way of calling web services (.ASMX pages) as WCF has pretty much made that obsolete. However, learning many different ways to skin a cat can be useful in an endeavor to find what fits you best.
Again, this is VERY high level, but these are very general topics with a lot surrounding each, so hopefully a high level overview will help direct you in studying deeper on each subject.
Some people mean "ASMX" when they say "Web Services".
Others just use "Web Services" to mean the generic technology, and consider WCF to be the current way to create Web Services on the .NET platform. The other kind are "ASMX Web Services", as distinguished from "WCF Web Services".
The "other kind" are a legacy technology, supported only for backwards compatibility. They should not be used for new development, so there's no point in you learning about them.
As others have stated, "REST" is an architecture style, not a technology.
WCF is multifaceted, so I'm going to speak of it with respect to its most common usage. The general difference between WCF and REST services is centered around the content. A REST call is usually more message/document/entity centered (With customer entities, find those starting with M; With order entities, get order 12 and is tied to the HTTP protocol. WCF tends to be more operation centered (Invoke find operation with params, Invoke get operation with parameters). WCF also isn't tied to HTTP.
FYI, there are extensions to create REST based services using WCF (WebInvoke, WebGet attributes).
Wcf:wcf is a technology as part of .net framework which provides environment to work with different distributed technologies an by following unified programming model.
wcf create a proxy.
wcf support data contract serializer.
records shown xml format.
**Rest:**Rest is an architectural style.which says use the existing features of the web in more effective,efficiency and simple manner.verbs like insert,update and delete.
Rest cannot create a proxy.
rest records shown jason format.
Web Service:a service which is hosted on website is called as webservice.
web service support xmlserializer
I see this is quite an old thread, but I have asked a similar question recently.
The answers given have all similar relevance, but in my opinion Ray was the closest to what was actually asked.
When designing or refactoring a web based solution, you always get the question should we go with SOAP or REST. The answer lies in the complexity of the business logic required behind the service. REST is good for simplistic API calls that usually contains small sets of requested data or over night processing with large sets, but mainly for data requests. SOAP is more of an interactive day to day service with business logic as well. For example many methods with plenty of parameters.
What we do as part of our web based solution, is to try and make use of both. For internal methods and primary functionalities we use SOAP, but for exposed APIs we prefer REST.
Framework related, definitely WCF as preferred choice, irrespective if SOAP or REST.
I'm pretty much a novice as far as WCF goes and I'm trying to figure out which type of WCF project to create for use by my windows phone 7 application.
There seems to be :
WCF Service
Silverlight-enabled WCF Service
WCF Data Service
As far as I can tell - #1 is an older variant, requires more configuration and an interface. #2 has some switches turned on that are required by Silverlight. #3 Talks to an entity model.
I am using an entity model so #3 looks good, but the examples I have seen look like it exposes the whole entity model. I want to pick and choose what tables to expose, plus create my own service methods using linq to join tables. Can #3 do this?
#2 looks better than #1 as it does not seem to require an interface and seems to have less configuration.
#1 looks most configurable which is both a good and bad thing. I guess this is my fallback position.
Any advice?
Cheers
Steve
What you're running into relates to the fundamentals of Silverlight (at least as it stands today.) Your conclusion is correct - the "Silverlight-enabled WCF Service" is probably your best bet for a quick service to call from the Phone app, but I'd like to offer a different take on the rationale.
Silverlight only supports a subset of the communication options offered by WCF - it only allows BasicHttpBinding, whereas WCF offers a whole lot more, including support for "enhancements" that are part of the WS-* specifications. As a result, you need to set certain flags and make certain choices in your WCF services in order to make them consumable by Silverlight. By using the "Silverlight Enabled WCF Service" template, that work is done for you. This also means that if you want secure web-service communication with Silverlight, you have to use/set up HTTPS.
As to the interfaces, etc., actually that works across both options - the need for setting up the ServiceContract vs "implying" it from the defined operations came around .Net 3.5 SP1, if my memory serves me correctly. Note that while "regular" Silverlight also has support for communicating with TCP-based WCF Services, I believe the phone does not.
Now for choice #3 - the WCF Data Service (or the artist formerly known as ADO.Net Data Services.) What this does for you is sets up a REST-based service to expose your backend data (where the previous 2 options are more/usually SOAP-based.) More details and introductory information on this can be found here - http://msdn.microsoft.com/en-us/data/bb931106.aspx. Now these services typically leverage plain old http, and are definitely consumable by Silverlight and the phone; also their payloads are lighter weight than the SOAP counterparts.
Whether or not to use REST or SOAP is a design choice - the SOAP approach is more RPC-like (define methods in the service that get called to perform specific actions with specific priorities), the REST option is more OOP-like, with some "auto-magic" thrown in for good measure. The thing about "auto-magic" is that you really do need to understand the magic (and its limitations) before you start, or your design could likely fail to meet your requirements.
Hope that helped!
John
There a lot of different ways a Silverlight application can connect back to it’ server. Including
WCF - Windows Communication Foundation
REST (see also)
ADO.NET Data Services (or is this just REST?)
POX - Plain Old XML (E.g basic xml)
RIA services
For each of these please say what it’s for and when you would or wouldn’t use it. I am not looking for a great level of details just a set of “rules of thumb” for choosing between them.
(The problem is when designing your first Silverlight application knowing what to use when you don’t have time to learn all of them.)
If I was to replace Silverlight with WPF in this question what effect would it have on your answers? (I am assuming with WPF that due to firewalls and admin policies a direct connect to the database is not an option.)
My two (euro) cents:
WCF seems best suited when the service can be viewed as the business layer of the application, that is, when your service has "intelligent" operations like "CalculateDiscountForClient".
ADO.NET Data Services (indeed, just a REST implementation) seems appropriate when your application is basically data-centric and the service is simply a front-end for the database. That is, all your service methods are of type GetCustomers, CreateInvoice, etc.
RIA services is a very new technology that I haven't experimented with yet, but it seems to be useful to create applications in which the Silverlight part and the service are very tightly coupled: you define your service classes and methods in the service project, and they are automatically replicated to the Silverlight project in design time. Also, you can define both WCF-style "action" methods and ADO.NET Data Services-style "data" methods. Looks promising.
Use POX if there is a chance that you change the client part from Silverlight to any other technology (for example HTML+AJAX) in the future, since it is the most interoperable option.
About differences for WPF, the only I can think of, is that for data access, whenever possible I would use direct ADO.NET data connections (properly embedded in a data access layer, LINQ to SQL or the like) instead of ADO.NET Data Services, since it is way more flexible. I must say anyway that I have never developed anything in WPF.
We use RIA, and that's the only one of the options that I know, but I do know it, so here's some of my thoughts.
RIA isn't finished yet. It is being worked on. If you are planning to be finished soon, and you're worried about having to support something that has a potential to change quite a bit, then you might want to consider other options. If this is a new project, and you're going to be supporting it for a long time, RIA will probably get easier to use.
Having said that, I kind of think that there won't be many changes in the way the July Preview of RIA works and the way that a finished version will work. Also the level of support seems to suggest that this will become "The Way" to talk to a server in Silverlight.
Just cause it's worth mentioning, have some links:
http://blogs.msdn.com/brada/ Brad Abrams has an example that he is continually updating.
http://forums.silverlight.net/forums/53.aspx this is where you go to ask questions.
http://www.riaservicesblog.com/Blog/ Colin Blair knows his stuff, and he is very helpful.
I think I would not go POX ever again. If you write WCF so that the service itself is independent of the binding and binding is done in configuration files, then WCF is pretty much agnostic about transport and protocol. It can do SOAP, JSON, REST, or its own form of binary serialization. All of this is in the binding. Internally, WCF only specifies what gets exposed in terms of operation and data contracts (all defined by class, method, and property attributes). WCF gives you tremendous flexibility in this regard, with more to come in 2010.
From the Silverlight side, WCF requires that you write some plumbing code. The .NET frameowrk has the tools to build the proxy in your Silverlight project, but you must be prepared to handle all WCF responses asynchronously, and the proxy cannot catch exceptions thrown by the service.
.NET RIA Services hides all this. It uses WCF under the covers, but that is completely hidden. You don't have to write asynchronous code. You define validation once, mostly declaratively, and it works both server-side and client-side. Release 1 will be targeted for Silverlight, so you don't get the versatility to use the service elsewhere. That scope is supposed to be broadened in later releases.
I don't know enough about ADO.NET Data Services to compare. I suspect the answer would depend on whether you want to expose your data to more than just Silverlight usage.
.NET RIA Services looks like the direction I'd want to go (looking at these issues myself, with a large application in mind). The big issues for me will be implementing a very large collection of functionality in the service layer, and not being able to code directly to the data access layer (we have to be able to run on either SQL Server or Oracle).
Using WPF instead of Silverlight changes everything, depending on where your data resides. It's like the old question of Winforms vs. ASP.NET. With WPF, you're building a Windows client app, and you don't need to use any form of service-based data interface at all, unless your data access forces you into it. You'll still want to separate data and business from presentation code, using MVVM, MVC, or MVP. Other than that, you have the option to treat data access as a layer, rather than a wholy independent tier.
WCF is Microsoft's standard for service communication. I would strongly advise anyone to create a service layer using WCF Web APIs (uses WCF, but tailored specifically for REST), which is coming out this April 2012. WCF Web APIs is currently in preview mode.
Remember these rules of thumb:
- your UI will change faster than your service layer. RESTful services will be around in several years, Silverlight probably won't
- will your services ever be APIs? Well...WCF REST is the way to go
- will you mix JavaScript and Silverlight code? WCF REST will make your life easier
- will you have a mobile component (since Silverlight won't run on iOS or android)...REST is preferred.
Don't tailor to the technology, but the app as a whole.
If you want to create a Silverlight Application and you do not care about other clients, then I would choose RIA Services. It is quite painless to use and you do not need to worry how the connection from the client is made (i.e. no client side configuration necessary). RIA also generates classes for all your entities on the client and you can even share your own "server" code with the client if required (useful for enumerations or extension methods).
Remarks:
I never tried this, but if you really need you can access the RIA Service also with other clients, after all RIA Services are built on top of WCF services.
I do not quite understand Akash Kava's security concerns. You can (and have to) control security on the server-side as you would do with any other service.
This article talks about consuming WCF services in Silverlight, but claims:
There will be no proxies, no generated code, no 3rd party utilities, and no disgusting "Add Service Reference" usage.
What is so wrong with me adding a service reference in my Silverlight project? Are there hidden overheads? Or is it a case of Fear Of Auto Magic on the part of the author?
The reasoning for that statement from the author appears to be:
To begin, let me start off by reminding everyone that you shouldn't ever use "Add Service Reference" in Visual Studio for magical service client creation. The code is incredibly verbose, hard to manageable, edits are prone to being overwritten, and it's almost always used as an excuse to not actually learn WCF. There are few things worse than having to deal with people who thing they know a product simply because they know how to use a mouse.
As someone who has relied on the "Add Service Reference" in Silverlight exclusively I think that is a bit over the top. I'd agree that the auto-generated code is verbose and it shouldn't be edited because it WILL be overwritten. However as far as manageability goes it doesn't get any simpler, in response to my service changing it takes one click to get the service reference back in sync.
Despite that I think the article is very good and I can vouch that the ease of adding service references has stopped me from delving deeply into WCF. That's not necessarily a bad thing as at the end of the day WCF is plumbing and I'm interested in writing my app not becoming a WCF expert. As it happens I have now reached a point where I am encountering some serialisation issues between Silverlight and my service which I suspect are related to the browser. I'll need to dig deeper into WCF to sort it out and that article looks like th perfect starting point.
The "Add Service Reference" has been fine for me for 1.5 years and while of course there are benefits to learning about the internals of WCF there is definitely nothing wrong with having a quick and simple point and click way to get started from within Visual Studio.
"Adding a service reference" in Silverlight has some problems right now...the config file gets regenerated each time the service is updated.
It goes a little further than the "auto magic" people are stressing as a problem. First, with a service reference you are "coupled" to the service and it's methods it exposes. If you re-generate the service the client has to do the same. Creating the service dynamically alleviates that problem. Furthermore, with abstraction/reflection/Dependency Injection you now have decoupled service references.
I don't think service references are bad, however WCF and web concepts are moving away from it. For example, WCF REST standards have no "service reference" that you consume...its just URL routing tables. More and more people are recommending this as a standard, for example Juwal Lowy (idesign.net and author of a couple WCF books) recommends not using service references as well.