I am working on creating a Windows 8 application. UI is using HTML5. Using WinJs I am calling a WCF service that returns a datatable used to build out the UI. All that is good.
I would also like to create a Window Service that gets packaged up with the application, so when someone download/installs it gets unpackaged and the windows service is started/executed. Is this type of configuration possible?
The WCF service today is a web service, but I would like to make it a windows service. The idea is to make everything self contained. This would allow me to make it available in the Microsoft Online store - if I wanted to go that route.
Windows 8 Applications don't support installing services. The best you can do is install a service separately.
Your WCF service should be decoupled from your app and most probably running on a different machine! I am pretty sure that the they are not going to allow you to install or run services in context of a Windows Store App.
Installing a windows service is not an ideal approach for any Windows 8 application. I understand that you want to make everythig self contained but, why as a WCF local service then? Why don't you consider having it has a data access layer in your app itself? Just a thought.
REGARDING CLIENT SIDE
Web services are separate projects and separate deployment models. You can have one Visual Studio project for the Windows 8 client app and one project for the Web Services side.
Windows 8 apps have several options for saving persistent data, such as endpoints for consuming web services.
There are several consideration when storing Windows 8 application data, such as the location of web services to be consumed.
Windows 8 Application data also includes session state, user preferences, and other settings. It is created, read, updated, and deleted when the app is running.
There are 3 types of dimensions to consider. The system manages these data stores for your app:
(1) local: Persistent data that exists only on the current device
(2) roaming: Data that exists on all devices on which the user has installed the app
(3) temporary: Data that could be removed by the system any time the app isn't running
As a developer, you concern yourself with a couple of objects to persist application data:
The first container object is ApplicationDataContainer. The other is ApplicationData. You can use these objects to store your local, roaming, or temporary data.
REGARDING SERVER SIDE
Your Windows 8 Client app will consume http-based web services.
Most developers deploy web services to the cloud to be consumed by iOS, Android, Windows, and other server side services.
Windows Azure is a cloud offering that makes exposing services to clients very simple.
You can leverage either cloud services for robust solutions or the lighter weight Azure Web Sites.
You can typically choose either of these two project types to create web services:
(1) Windows Communication Foundation WCF; or
(2) ASP.NET Web API, which is included with MVC version 4.
WCF has been around longer and has historically been the primary choice for developers when it comes to exposing services.
Microsoft's more modern concepts about web services relate to the ASP.NET Web API, which truly embracing HTTP concepts (URIs and verbs). Also, the ASP.NET Web API can be used to create services that leverage request/response headers, hypermedia, etc.
Related
I am working on a product for Windows 8 that needs to perform some low-level tasks, display some UI, and communicate with an external server. I definitely need a Windows service to accomplish the low-level tasks. At the same time, I would like to use the cool features of Windows App Store apps, like push notifications, live tiles etc... for the UI. In this design, both my service and my app would communicate with my external server.
The flow would be something like: my Windows service sends some information to my server, which then sends a push notification to my App Store app.
I understand that deployment is not pretty in this scenario, but let's put that aside for now. My problem: How does the server know that the service and the app are on the same machine, and consequently linked together? i.e. When my Windows service sends information to the server, how does the server know where to send the push notification? I need is some sort of shared, unique, identifying information.
I have seen lots of discussion (usually frustrated in nature) about the lack of inter-process communication between App Store apps and desktop apps. In my case, I have two options:
Generate the exact same unique identifier in the service and in the app. This seems unlikely because apps don't seem to be able to access very much system-specific information. I'd love to be shown that I am wrong about this.
Generate a unique identifier in the server OR in the app and communicate it to the other component. Potential ways to do this:
Create the identifier in the app, save it to a file, and then access the file from the service.
Some sort of local socket solution (I've read this doesn't work, but have not tried)
Of course, option 2 seems likely to violate the Windows 8 app Certification Requirements, notably:
Windows Store apps must not communicate with local desktop
applications or services via local mechanisms, including via files and
registry keys.
Any advice would be most appreciated.
I'm not a lawyer, but if it says "via local mechanisms" then you could still possibly communicate via a cloud service as long as having both apps installed isn't necessary to have some features in the app or if you don't mean to publish the app in the store.
You could save some sort of a token in the documents folder or if your desktop app can run with appropriate permissions - it could access the local data folder of the Windows Store app to synchronize the token for use in communication with the web service.
Perhaps the user could just be asked to copy and paste a token between the two apps?
I'm researching some Windows Azure stuff, in order to make a decision whether to move to Azure or not.
Basic information
To answer the question, you'll need some basic understanding of my app so here goes.
The app is an ASP.NET MVC 3 application that connects to a SQL Server database.
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server, deployed to IIS 7 as a website.
I have one SQL Server, where each instance has its own database.
I also have a set of Windows Services to do some background processing. That should be straight forward, as I'll just rewrite those to use a Worker Role in Windows Azure - most of the logic in the services is located in their own class (library) anyway, so the service it self just calls one or more methods in a class.
Now to the question
Whenever someone signs up for a free trial, I add a record to an Admin database I have.
I then have a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders, runs the database deployment script and updates the record to reflect that it has now been deployed, and finally sends an e-mail to the prospect that their free trial has been created - here's how you access it.
So, how can I deploy a new instance in Windows Azure from a Worker Role? Preferably, I'd just add a new website to an existing Azure instance and create a new SQL Azure database for that particular site to use.
Does this require a lot of work to set up? Is it even possible?
Based on two quotes, I would like to suggest calling this a multi-tenant application:
It is a single instance application, meaning that every customer eventually has their own instance of the app running on our server,
And...
a Windows Service that deploys a new instance of the ASP.NET MVC 3 app to IIS, grants permission to a few folders
If I understand correctly, there is "one" IIS server (well, in Windows Azure, it's one Web Role, scalable to multiple instances), and with each new "tenant", you set up some new stuff to support that tenant.
If that's indeed the case, you can definitely do this from a worker role - just look at Nate Totten's multi-tenant web role blog post and related code. Look at the webdeploy code that actually manipulates IIS.
Further: take a look at Cloud Ninja, a project a few of my teammates published along with Fullscale180. This is a multi-tenant app that demonstrates how to manage multiple customers in a single deployment, as well as monitoring and scaling.
Finally: should you need to actually create brand new service hosts and storage accounts, the latest updates to the Windows Azure Management API support this.
I hope that helps a bit...
I think most of the things you want to achieve are possible.
It will definitely require some work to setup!
For some ideas on how to achieve what you are looking for, take a look at the MS SaaS example - http://www.fabrikamshipping.com/ - especially designed for porting existing apps to SaaS on Azure. Inside this app they have an "onboarding process" - and that process includes setting up new SQL connections and new portals.
There's lots of good blogging (watch the video) about this on http://blogs.msdn.com/b/vbertocci/archive/2010/10/07/new-online-demo-introducing-fabrikamshipping-saas.aspx
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
I have a WPF application that uses LINQ-to-SQL on a local .MDF file. This solution is simple, easy, and effective, i.e. I set up my model once, then read/write data anywhere via LINQ:
using (var db = Datasource.GetContext())
{
oldItem = (from i in db.Infos
where i.Id == TheId
select i).SingleOrDefault();
CreateForm(db, FormBase, oldItem, Button_Save);
}
What is the dead-simple equivalent of this for Silverlight apps?
Searching I find an explosion of terms:
WCF RIA Services, WCF Data Services (ADO.NET Data Services, Astoria), Data Services Toolkit
.NET RIA Services
OData(Dallas)
GData
REST, REST-based, REST-like, REST-inspired
XML, JSON, RDF+XML
web services, SOA
cloud-based services, Azure, SQL Azure, Azure Services Platform
All I want to do is this:
create an .mdf file
use some LINQ-to-SQL-like tool to generate a web-enabled (REST?) data layer etc.
ftp the .mdf file and classes up to my ASP.NET web hosting service
write silverlight clients that read and write to this data source with LINQ
Concentrate on learning RIA Data Services, or WCF Data Services. It converts your LINQ queries inside Silverlight to REST requests, and saves you from writing some of the infrastructure code. The whole idea is that your SL app communicates only to web services, you don't have access to physical DB, like when you're using some ORM (L2S). In SL, your are inside browser's sandbox, which prevents you from accessing file system, including db files.
Other approach is to write web service and expose data through it (GetArticleByID), and then you consume that services from Silverlight. Then you use LINQ to iterate on fetched, loaded data.
Here's what to do -
Create a Silverlight app using Visual Studio. You will get two projects, one with the Silverlight XAML, and the other a web application to host it.
In the web application, add your DBML (Linq-2-SQL) file. Configure as normal
In the web application, add a Silverlight enabled WCF service
In the WCF service, define some methods that access the L2S data context
In the Silverlight project, go to add Service Reference, hit "discover" and add the WCF service in
Instantiate the service, and access your methods
Sounds a little complex, but pretty straight forward in practice.
Not possible. Silverlight cannot access databases directly. Some sort of web service layer is required in between. I think WCF and RIA Services are the most widely used.
I would strongly recommend that you clear an hour in your schedule and just watch this video:-
net-ria-services-intro
In fact clear 2 hours and work along side the video building your own copy of the app being built.
If you want to develop a regular LOB (Line Of Business) Application, then you should follow the approach using a web service interface to your database. The RIA services or WCF data service is the current RAD (Rapid Application Development) technology by Microsoft to make this task easier.
If you're talking about a special scenario you need: Silverlight 4 when running out of browser can talk to COM servers on windows now. Talking to databases is described in this vast blog post: Cutting Edge Silverlight 4 Com Features.
If you're looking for a way to manipulate database-like files, you may take a look at the csharp-sqlite project. I think it compiles for Silverlight without much ado (quick and dirty proof of concept here: Proof of Concept csharp-sqlite in Silverlight). With it you could create and manipulate a database file in the user's isolated file storage in a regular Silverlight application and then upload it to wherever you desire.