i am new to the concept of silverlight and understood few things from this site.
i want to clear my doubt that what is the role of wcf ria services in silverlight applications?
what do we mean by domain services?
In Silverlight, you do not connect to a database directly - your Silverlight app runs on the client machine after all. The client-side UI (Silverlight) and the database / backend are strictly separated. The number of classes that the Silverlight runtime has to offer is (by design) quite limited, and things like direct database access are not amongst those classes available.
The way your SL app gets its data is through a WCF service (Domain service, or WCF Data Service) running on some server, which accesses the database on your behalf. This part usually runs on your web/app server and has access to your database or other backend servers.
The domain services are the one who gives you access to a remote repositories using WCF technology. That Silverlight compact .Net framework is on the clientside which needs to access services through cloud (internet) in able to interact data to the users.
You can start in http://www.silverlight.net
Happy reading!
Related
I'm just wondering how to approach to my project.
In my application I have:
MVC4 project
DB_Project with Interfaces and Models
Repository_Project with interfaces implemantation - I'm using Ninject
Next step is mobile app(XAMARIN), and here is the question:
What kind of WCF project should I choose and why...WCF Service Application or WCF Service Library?
Should I add this project like any other or create separate one?
After choosing WCF project, how to use reference to Repository_Project - is this the right way?
I will give you some thoughts to consider.
1- Your Xamarin app must communicate with an asp.net web api / mvc exposed to the internet. I dont recommend exposing a WCF service to the internet for many reasons.
2- In the Data layer, repositories are abstractions to access your EF dbContext and not to call WCF services.
3- You only add complexity when justified. If you are willing to create WCF project for the xamarin app to communicate with, then i hardly discourage you. WCF project may be created in your case if you have some security policy that enforces 3-tiers architecture where the web api needs a middle tier to access the database. Otherwise, you dont need it.
2-tiers:
Xamarin -> web api -> SQL Server
3-tiers:
Xamarin -> web api -> wcf -> SQL Server
I'm planning to develop a pos application for restaurant. Client will be using pc and mobile. Application will be used in local area connection. I'm still considering whether to go with wcf or web api. What are the advantages of using wcf/web api for the type of application i'm building?
Use WCF to create reliable, secure web services that accessible over a variety of transports.
Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients.
Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API.
If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.
from the official Microsoft Documentation.
Essentially, my take on this is that WCF is much more difficult to work with, and not completely compatible out of the box with many mobile clients, so only use it if you know that it's something you need.
The company I'm working at does not have a great Infrastructure, it is treated as one big network, there is no network segregation. As such when were developing applications we have a TEST/UAT/PROD/DR setup. I have been developing a suite of services that have been deployed on all the above regions. How do i make sure that a developer can not call a production web service by accident? Is there anyway to restrict the service by caller (ie: server name?).
BTW all these services are internal and are not externally available.
Thanks Again for your help.
Josh
You could use Role based Authorization
Authorization In WCF-Based Services
I need to create a web service to collect data from my customer’s applications.
Those applications are programmed with different technologies and they all have one thing in common: they can consume plain SOAP Web Service.
I already have a WCF Service that could be exposed but as it was built for internal purpose only, I never had to secure it.
I did read a lot of articles on how to secure WCF service and how to consume it from a Microsoft client application. However, I'm really concern about the customer’s non-microsoft applications abilities to implement a standard WCF Service security. I must keep in mind that some of them might be stateless and unable to hold on to a session or anything that might be required by a secure WCF Service.
So here are the options I have right now.
1) Add username/password parameters to each WCF function and perform a credential check on every call. (I do have an SSL certificate... is it enough to consider this option as secured?)
2) Drop my WCF Service and create a plain SOAP Web Service with username/password parameters as mentioned in option #1 to be closer to my customer’s applications capabilities.
3) Implement standard WCF security and let the customers find a way to deal with it on their own. (The real question here: is WCF security simple enough to be implemented by any SOAP client?)
4) Change my name and move to Jamaica with my customer’s money before they find out that I’m a Web Service security noob.
5) Something else…
So what is the my best option here?
Yes, I can offer the option we use. It sounds like you want basicHttpBinding.
We have a WCF web service using basicHttpBinding and set IIS to use basic http authentication.
Therefore non-.NET clients can consume it easily (basicHttpBinding) and we can give them an Active Directory domain account that allows them access via IIS. No usernames / passwords to constantly send back and forth through the web service and it runs over HTTPS for security.
It's currently being consumed by PHP, Java and .NET clients. Yes, .NET clients can still import this as a service reference which makes thing like trapping FaultExceptions easier.
No solution is perfect for everyone but works great for our needs.
Yes, but certain configurations favour certain vendors. See the WCF Express Interop Bindings project on CodePlex:
http://wcf.codeplex.com/wikipage?title=WCF%20Express%20Interop%20Bindings
They offer settings for interop with:
Oracle WebLogic
Oracle Metro
IBM WebSphere
Apache Axis2
The Oracle Metro (previously known as SUN WSIT) stack is by far the most advanced as regards the WS-*/Oasis standards.
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