We currently have a Silverlight 2.0 application communicating with a set of WCF web services. These services communicate with other WCF services for business logic.
Client DMZ Intranet
Silverlight -> WCF Web Service Gateway -> WCF Biz service -> DB
The WCF web service gateway resides within the DMZ.
We see that Ria services can replace our WCF web Service gateway, but this means that it will be installed in our DMZ and have access to our database... Is this secure?
We also seem to loose our business logic WCF services... I would need to put the business logic within Ria services (as it has connection to the database and holds the domain...).
What is the recommended patter for Ria services? Where does it fit?
What is the approach for companies that already invested in WCF web services? Can they use RIA?
We are looking at this alternative, were we would expose both web services and Ria...
Silverlight -> WCF web service - > WCF biz service -> DB
-> Ria services -> DB
Any comments? I also wonder if anyone is actually using Ria in production....
Your proposal architecture with the silverlight app calling
both WCF Services and Ria services sounds fair to me.
Suppose your DB has an Employee Entity.
I can get this approach up and running, but have some issues
Suppose "the WCF biz service" accesses and modifies Employee.
does it get this data from the database directly?
(if so, is the EntityFramework edmx model shared between "the WCF biz service" and ria?)
does it in turn uses the RIA layer, and thus the EmployeeRiaProxy?
..?
Suppose you want to use the Employee Entity on your "WCF biz service" operation contract
This should not be possible in a pure SOA architecture?
Use a pure DTO data contract style approach with an EmployeeDto?
Should you use the Employee, or the EmployeeRiaProxy?
Using the Employee is not possible because the silverlight app does not know it
(or would cause another EmployeeWCFProxy type being created on the client)
Using the EmployeeRiaProxy is possible, but ties your operation contract to a
Ria proxy (pretty poor design) and assumes the service uses RIA for data access
Or should everything pass through this RIA layer? from which you call "the WCF biz service" in turn then?
Any opinions welcome!
Koen
Related
What is the difference between WCF Data Services and WCF Web API?
WCF Data Services is a framework on top of WCF that makes it easy to create RESTful services that "talk" Atom/OData based on specified LINQ context (object model, LINQ2SQL or Entity Framework).
The new WCF Web APIs are currently under development, and will enhance the existing WCF framework to build better HTTP/RESTful services in general.
--larsw
I have a database that doing simple CRUD and connected via BizTalk Server 2010. Since Lightswitch is very simple and looks fits for that CRUD operation, I want to introduce Lightswitch for the operational staff here.
(I am not an expert in both technologies) the problem is, Lightswitch consumes WCF RIA Services. While BizTalk by default cannot expose such type of web services.
my question is :
what is the best type of web-service should I expose from BizTalk in order to be consumed by Lightswitch?
The easiest option is to throw a proxy service in between. You can take a BizTalk-generated WCF endpoint and wrap that service call with another service that exposes the DomainService that LightSwitch asks for.
For example, see this LightSwitch team blog post http://blogs.msdn.com/b/lightswitch/archive/2010/10/22/how-to-create-a-ria-service-wrapper-for-odata-source.aspx
Does anyone know how to host a WCF Data Service (or OData) inside IIS7? I'm seeing lots of articles about hosting WCF, but none specific to WCF Data Service.
Thank you very much.
Hosting a WCF Data Service in IIS is actually the default option.
Its a pretty easy 3 step process:
Create a new WebApplication project (or re-use an existing one)
Add a WCF Data Service to the project
Deploy to your IIS server
Step 3 is just the standard process for deploying a WebApplication to IIS.
A WCF Data Service is just a WCF (REST) service, with some additional out-of-the-box functionality added in.
It has a *.svc file and all - it will be hosted very much the same as a "regular" WCF REST service.
So all the articles you see about WCF REST should really apply to WCF Data Services as well - or are you experiencing some difficulties with something specifically??
I am new to WCF and Web Services in general. What are the improvements that WCF brings to the table? Can anyone give a side-by-side example of a traditional web service and the same one written using WCF and point out the differences and advantages?
Duplicate question Moving ASP.net webservices to WCF
EDIT: Think i found the answer you where looking for a side-by-side code based comparison and even better it's from MSDN: Comparing ASP.NET Web Services to WCF Based on Development
There are several related questions:
Difference between aspnet web method and wcf webservice
Benfits of using WCF
Moving aspnet web services to wcf
However you asked for a side by side comparison in which case i think Sam's Wcf vs ASMX blog article is more what you are looking for.
Quoting ad-verbatim (let me know if i should just leave it as a link):
WCF vs. ASMX
Protocols Support
WCF
HTTP
TCP
Named pipes
MSMQ
Custom
UDP
ASMX
HTTP only
Hosting
ASMX
Can be hosted only with HttpRuntime on IIS.
WCF
A WCF component can be hosted in any kind of environment in .NET 3.0, such as a console application, Windows application, or IIS.
WCF services are known as 'services' as opposed to web services because you can host services without a web server.
Self-hosting the services gives you the flexibility to use transports other than HTTP.
WCF Backwards Compatibility
The purpose of WCF is to provide a unified programming model for distributed applications.
Backwards compatibility
WCF takes all the capabilities of the existing technology stacks while not relying upon any of them.
Applications built with these earlier technologies will continue to work unchanged on systems with WCF installed.
Existing applications are able to upgrade with WCF
New WCF transacted application will work with existing transaction application built on System.Transactions
WCF & ASMX Integration
WCF can use WS-* or HTTP bindings to communicate with ASMX pages
Limitations of ASMX:
An ASMX page doesn’t tell you how to deliver it over the transports and to use a specific type of security. This is something that WCF enhances quite significantly.
ASMX has a tight coupling with the HTTP runtime and the dependence on IIS to host it. WCF can be hosted by any Windows process that is able to host the .NET Framework 3.0.
ASMX service is instantiated on a per-call basis, while WCF gives you flexibility by providing various instancing options such as Singleton, private session, per call.
ASMX provides the way for interoperability but it does not provide or guarantee end-to-end security or reliable communication.
WCF is far wider in scope than ASP.Net webservices.
WCF can run in any application. APS.Net webservices only run in IIS.
WCF supports models like ReST, Remoting, SOAP, MSMQ etc. ASP.Net only supports SOAP
WCF is more configurable.
WCF supports a more declarative way of programming. You can get more done with less code.
ASP.NET Web Services are pretty much just that. Web Services. They're SOAP/WSDL based and provide their services only to the web.
WCF Services offer a much more flexible framework. For instance, depending on how the service is defined, it can be a Web Service hosted in IIS which serialized its data via XML and uses the REST model...or it can be a Remote Windows Service that is hosted in it's own process and serializes its data via binary. All of this is achieved using the different Service/Data contracts in WCF.
In short...you can make a WCF service look almost identical to a .NET 2.0 Web Service fairly easily but, with a little work, you can do a WHOLE LOT MORE.
We are in the middle of creating an n-tier Silverlight LOB application and are considering the use of .NET RIA Service. We are unclear where this fits in relation to our current WCF service API. Our Current architecture is:
Silverlight <--> WCF Service <--> Business Logic <--> Entity Framework Model <--> Database
Having watched Nikhils Mix 09 presentation it would appear that .NET RIA Services would replace our WCF and BusLog sections:
Silverlight <--> RIA Services <--> EF Model <--> DB
Which is fine, expect that we need to have a standard SOAP endpoint API exposed for use by other applications (Biztalk,Integration etc). Can .NET RIA Services be exposed as SOAP endpoints without the asynchronous requirement?
How easy is it to implement a WCF service over a .NET RIA Service? Do you know any good online examples of this?
Thanks,
Mark
Yes – In the next CTP for RIA Services we will have some very nice support for defining WCF service (via Astoria and eventual vanilla WCF) that exposes your business logic in RIA Services. So you’d have two heads on your RIA Services implementation.
Silverlight <--->
RIA Services <---> EF Model <---> DB
WCF Services <--->
I’d say this model makes sense if the primary goal is the Silverlight application, however if the primary goal is the WCF service, I’d hang with the model you have today.. Does that help?
..brad
We're looking at the exact same scenario. Right now, we're thinking of going with this model:
Silverlight <--> RIA Services <--> WCF Service <--> Business Logic <--> Entity Framework Model <--> Database
We will be able to host our WCF services in a variety of bindings. We'll use an inProc call from RIA to WCF for the Silverlight app. For external consumers of the WCF services, we'll host them with a wsHttp endpoint.
Thus in our scenario we get the best of both. RIA services becomes part a set of presentation services for our app that eases the burden of programming the Silverlight app (i.e. async). The downside is that we've added an extra layer.
Thoughts?