I'm currently developing a WP7 app, and I'd like it to talk with my SQL Azure database. I know there are currently two ways of doing it:
Talk to a WCF Service hosted on my web server.
Use oData to communicate with my database.
I don't know what's the pros and cons between the both of them, but I know that using the first method involves two remote calls: one: to the web server, and two: from the web server to SQL Azure. Would using oData allow me to directly communicate with my SQL Azure database? Does SQL Azure provide a REST interface for my WP7 client to work with?
If you use the WCF service approach and host the service on our web server (i.e. not in an Azure Web Role) then yes there will be two higher latency hops across the network. However the WCF service does have the benefit of allowing you to provide your own security approach for your mobile clients. I suspect that this app will be used by more than just a couple of people? If you take the approach of talking directly to the SQL Azure oData endpoint then you will really struggle with Authetnication and Authorization. It's not really designed for supporting your scenario.
The other thing to note with the SQL Azure oData endpoint is that it never left SQL Azure Labs; i.e. it was never actually shipped as part of the product and the Labs implementation is end of lifed and grandfathered to existing users only.
I know that doesn't really answer your question; the short answer is that there is no RESTful endpoint that you can access to talk directly to SQL Azure. The long answer is that even when there was one you probably didn't want to use it.
Without knowing more about your app it's a little hard to give guidance as to exactly what you should be doing. If you can provide a bit more detail I can provide some advice as to which Azure data storage technology would be best suited.
Related
I need quick help regarding Identity server.
There is a client requirement to not allow any public hosted application to directly talk to the database. In Identity server's case, the Identity server will be hosted publicly for token endpoint, and it queries the database for operational data (went for Db approach with reference tokens because IDsrv will be on NLB). Is there any workaround for this? or is this standard practice?
Thanks
If you don't want IdentityServer to talk directly to the database, you will need to implement & register custom implementations of ICorsPolicyService, IAuthorizationCodeStore, IClientStore, IConsentStore, IRefreshTokenStore, IScopeStore, and ITokenHandleStore, that call off to some an external app that can talk to the database.
Normal operating procedure is to have IdentityServer talk directly to the database. I don't see much merit in separating the two.
FYI: You don't need to use reference tokens if you are using load balancing. Check out the deployment docs.
I am now self-studying how to developing an App for Windows 8 with C# and XAML and I want to use Windows Azure service as a cloud server for my database, just like SQL. I am new to this technology and as far as I know mobile service is not for all-purpose tools, but still, I wonder if I can use it just like SQL, in which many tables are related to each other.
If not, what Windows Azure service I should use instead? Virtual Machine, perhaps?
The way you can simplify it as Windows Azure Mobile service replaces the basic requirement basic of any currently available SQL Database access API instead using WAMS your application can connect to same SQL Database over a Mobile service endpoint available to your app and that what makes independent to any app connecting to WAMS.
WAMS simplify quick creation and access to data backend (hosted in Windows Azure) from any mobile app so yes you sure can use WAMS with SQL DB as long as you have a fixed access scope with your SQL DB requirement. When I say fixed means even when Windows Azure Mobile Service (WAMS) use SQL Database as backend you will be limited within the functionality provided within WAMS framework compare to accessing your DB over API. As you already know there are tone of other things you could do directly with SQL DB (using API or other interfaces) but not by using WAMS. However once the SQL DB is created you still can access it outside the scope of WAMS and still can do the rest.
I heard that apps don’t port directly and they have to be specifically written to work with Azure. I’m new to Azure and did some reading but I don’t see anything from their site or documentation that suggests that you must specifically code for Azure, so is it true?
If this question is better suited for another StackExchange site please let me know.
You should take a look at the Windows Azure Platform Training Kit to see some introductory project labs.
While you theoretically can just "drop in" some apps into a Windows Azure VM, it hardly makes sense to do so. Some apps can be migrated with only minor changes, such as an asp.net website - session state is easily handled by AppFabric Cache, and the Web Role VM is Windows Server 2008 with Full IIS. However, you'd still need to integrate with Windows Azure Diagnostics, to be able to have external visibility to the health of your app.
Further, with the example above, there are more optimal things you can do, such as moving static content to blob storage, and taking load off your VMs. This requires you to upload this content, and then change your IMG and other tag URLs to point to a slightly-different URL.
Just remember that you're moving to Windows Azure to take advantage of its platform and related services, not just to be a rack to host a server. To take advantages of these services, you're going to have to target them specifically, such as:
Access control services
Caching
Connectivity (vpn, service bus)
Diagnostics
Database (SQL Azure)
Synchronization services
Traffic management across data centers
This is somewhat true. Your apps will typically run as-is. You just need to add an azure project to the solution, and add your MVC apps as roles to the Azure Project.
I found O'Reilly's "Programming Windows Azure" to be a good conceptual introduction to Azure.
I am trying to understand exactly an AppFabric in Windows Azure, What is the difference with Worker Role and Web Role and How to create a project of AppFaric in Visual Studio 2010, i mean which kind of project ?
Thx.
Adding a bit to vtortola's answer:
There are three core areas of the Windows Azure platform:
Windows Azure (which provides virtual machines and massively-scalable storage through Blobs, Tables, and Queues
SQL Azure (which is a large subset of SQL Server), offering a full relational database up to 50GB
Windows Azure AppFabric (a set of services that you can opt into, currently comprising access control, connectivity, and caching)
When you construct your Windows Azure application, you can really pick and choose what pieces of the platform you're interested in. For instance, Windows Azure provides Web and Worker roles (both essentially identical virtual machines running Windows Server 2008 or R2, but Web roles have IIS enabled). If you need a relational database, you can very easily set up a database. And, then there's AppFabric:
If you need to connect to a set of web services on premises, for instance, you can use the AppFabric Service Bus (a secure way to connect without having to open up a firewall)
If you need to actually connect to an entire computer on-premise, use Azure Connect (a software VPN).
If you want to cache data (such as asp.net session state) between instances of your virtual machines, enable and use the AppFabric Cache (currently a Community Technology Preview, so no pricing yet).
If you need to add access control to your application, use AppFabric's Access Control Service, which essentially lets you outsource your identity management.
There are quite detailed examples in the Platform Training Kit that vtortola referenced. Additionally, there's a complete Identity Management training kit.
Azure AppFabric is a suite of middleware services and technologies to help you develop and manage services/applications that use Windows Azure. Middleware is typically defined as software that helps connect other pieces of software, and this definition is pretty accurate for the services appFabric provides.
You don't create an App Fabric per say. AppFabric services are used by your other applications as needed, so setup is typically configuring certain items in the Azure Portal, then implementing libraries of config entires in your web/worker roles that leverage the resources.
Essentially AppFabric provides certain resources that you need when composing complex applications as services, vs. you having to implement and maintain these resources yourself.
The basic offerings are:
Service Bus: A message relay that can be consumed by other .NET technologies (and others). SB helps you connect different cloud services as well as "hybrid" services. The hybrid is a big deal, as SB helps you easily connect on-premise web services with services you run in the cloud, w/o having to mess around with VPN, protocols, server setups, certificates, etc etc.
Access Control: An authentication and authorization service, helping you manage user-level access without having to extend/implement Active Directory, LDAP, and custom user authentication modules throughout Azure.
Caching: an in-memory distributed caching layer for your applications. This is typical to memcached or the Windows Server version of AppFabric
Integration: a PaaS service of EDI/transport technology like BizTalk server
Composite App: allows the composition of complex applications using a compistion language versus just putting a bunch of code together. You basically define your application using a designer like you would a EF.Net data model or a Windows Workflow
So basically AppFabric provides you with a lot of services that you likely need, but the typical cloud developer may not want to "mess with" at least at first. This way you have these great building blocks to help you focus on your core logic/needs during development cycles while not limiting what your application can ultimately do. This "focus" is one of the core benefits to cloud computing, especially Platform as a Service, and is one area where Azure really shines compared to other offerings.
Some of these technologies are still in beta. The AppFabric site makes this very clear, but its important to be aware of.
Great place to start is the Azure AppFabric site itself, which breaks a lot of this down, gives you great examples of how to use, and some sample code for you to get your feet wet.
http://www.microsoft.com/windowsazure/AppFabric/Overview/default.aspx#top
Basically:
WebRole : similar to a web
application.
WorkerRole: similar to a Windows
service.
AppFabric: Group of services that
allow you interconnect applications inside and outside Azure.
Download and read/do the Azure training kit, it will solve those questions and tell you how to create that project in Visual Studio step-by-step.
I got a lot of theoretical answers from Google that WCF is better than Web Service etc. etc. But I want to know from the programming and implementation point of view. I am very new to coding and want to know that how do we implement all three of these technologies? How are they different and in which scenario we should used which technologies?
Thank you in advance.
A web service is an API that is hosted for access via a network connection - often the internet - and usually accessed over HTTP (or HTTPS).
WCF is a Microsoft .NET development framework that can be used to implement web services. That is, WCF-services are a subset of all web-services.
Windows services are a separate beast entirely: they are long-running programs that run on your local Windows machine, typically with no user interaction and on system accounts. They are used to handle many things in Windows, from low-level driver functionality to software updates.
You're really comparing apples and oranges. A web service is simply a program that you can "call" using the HTTP protocol. Typically, HTTP requests sent to the service contain some XML describing the method called and any parameters. The response from the service likewise contains XML with the return value and any output parameters. It's a little more complicated than this, but it gives you the basic idea.
Windows Communication Foundation (WCF) is a framework for building network services. You can use this framework to build web services if you wish. I suspect that what's tripping you up are the various Visual Studio project templates. You have one for WCF services and one for web services. The web service template builds a web service that runs inside of IIS. The WCF template gives you far more flexibility (you can make a web service as a stand-alone application, for example), but it is far more complicated.
If you're just beginning, I'd start with web service template and IIS-based web services.
MSDN is always a good reference:
Web Service Tutorial:
http://msdn.microsoft.com/en-us/library/8wbhsy70%28VS.80%29.aspx
WCF Tutorial:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
I think its always easier to learn by doing.
Good luck