Translation Azure Services Platform David Chappel Part 1
The second part of the translation
Using computers in the cloud can often be a very good idea. Instead of buying and maintaining your own hardware, why not use the mass of servers available and offered today via the Internet? For some applications, both code and data — both, can live in the cloud, where someone else maintains and maintains the systems they use. In other cases, applications that run inside the organization — local applications — can store their data in the cloud or use other infrastructure from the cloud. Applications running on desktops or mobile devices can use services in the cloud to synchronize data between different systems or for some other purpose.
In any case, whether the application itself works in the cloud or uses the services provided by the cloud, or both, you need something like a platform for such applications. Looking wider, under the platform for applications can be understood everything that provides the developer with a service for creating applications. For example, in the local Windows world, this includes technologies such as the .NET Framework, SQL Server, etc. For applications to use the cloud, there must be a cloud-based application platform. And since there are many different cloud applications for applications, different types of cloud platforms are useful in different situations.
The Microsoft Azure Service Platform is a group of cloud technologies, each of which provides a specific set of services for developers.
In Figure 1, the Azure Service Platform can be used both by applications running in the cloud and running on a local system.
Figure 1 The Azure Service Platform supports applications running both in the cloud and on the local system.
')
Platform components can be used by local applications running on different systems, including different versions of Windows, mobile devices, etc. These components include:
Each component of the platform plays its own role. This review describes them all, first together at a high level, and then each in more detail. Although none of the components are yet to be released - the details and much more may change before the initial release - it is not too early to begin to deal with this new platform.
At a high level, understanding Windows Azure is quite simple: it is a platform for running windows-based applications and storing the data of these applications in the cloud. Figure 2 - its main components.
Figure 2 Windows Azure provides services for running and storing data to cloud applications.
As can be seen from the figure, Windows Azure runs on a large number of machines located in Microsoft data centers and accessible via the Internet. The Windows Azure Factory binds all this computing power into one. Windows Azure data storage and execution services are built on top of this factory.
Windows Azure run services are based, of course, on Windows. For the initial available version (CTP became available to the public in the fall of 2008), only applications based on the .Net Framework can be run on Windows Azure. The company announced plans to support unmanaged code as well, that is, applications not built on the .Net Framework in Windows Azure in 2009.
In the CTP version of Windows Azure, developers can create .Net-based applications, such as ASP.NET applications and WCF services. To do this, they can use C # or other .Net languages ​​along with traditional development tools like Visual Studio 2008. And although most developers will most likely use the original version of Windows Azure to create web applications, the platform also supports background processes, who work independently of the web part is not only a platform for web applications.
Both Windows Azure applications and local applications can use Windows Azure data storage services, in both cases in the same way — using a REST-type mechanism. However, the data storage used is not SQL Server. In particular, it is not even a relational system and its query language is not SQL. Since the storage system is designed to support applications on Windows Azure, it provides simpler, more scalable types of storage. Accordingly, it allows you to store large binary objects (blobs), provides queues for interaction between components of Windows Azure applications, and even something like tables with a regular query language.
Running applications and storing their data in the cloud can have obvious benefits. Instead of buying, installing and maintaining their own systems, an organization, for example, can pass on to a cloud service provider all these concerns. Also, customers only pay for the “computations” and storage they use, instead of serving a huge number of servers only for peak loads. And if the applications are written correctly, they will easily scale, taking advantage of the huge data centers provided by the service provider in the cloud.
However, obtaining these benefits requires proper management. In Windows Azure, each application has a configuration file - Fig. 2. By changing the information in this file, by hand or programmatically, the application owner can control various aspects of its behavior, such as the number of running Windows Azure instances. Window Azure Factory monitors the application to maintain a specified state.
To allow clients to create, configure, and monitor applications, Windows Azure provides a browser-accessible portal. The client provides his Windows Live ID, then chooses whether to create a hosting account for running applications or a storage account for storing data, or both. The application is free to choose the method of charging fees from its customers - a subscription, a fee for each use or something else.
Windows Azure is a common platform that can be used in various scenarios. Here are some examples based on what CTP allows:
Running applications in the cloud is one of the most important aspects of cloud computing. With Windows Azure, Microsoft provides a platform for running applications in the cloud, and ways to store application data.
Along with the growing interest in cloud computing, wait for more windows applications created for this new cloud world.
Running applications in the cloud is an important part of cloud computing, but this is not all that is hidden under this term. You can also provide cloud-based services that can be used by either local or other cloud-based applications. The solution to this problem is the goal of .Net Services.
Initially known as BizTalk Services, .Net Services solve basic infrastructure problems when building distributed applications. Figure 3 - components.
Figure 3. .Net Services provides cloud infrastructure that can be used by both cloud and local applications.
Net Services Components:
Here are some examples of how .Net Services can be used:
As with Windows Azure, there is a portal available through a browser that allows customers to subscribe to .Net Services using Windows Live ID. Microsoft’s goal with their .Net Services is simple and straightforward: to provide a useful cloud infrastructure for distributed applications.
One of the most attractive ways to use servers available on the Internet is to work with data. Of course, this usually means providing a database engine, but not always the case is limited to this. The goal of SQL Services is to provide a set of cloud services for storing and working with a large variety of data types, from relational to unstructured.
Microsoft says that SQL Services will include various data services, such as reports, data analysis, etc. However, the very first component that came to light is SQL Data Services.
The idea is in fig. four.
Figure 4 SQL Services provides services for working with data in the cloud.
SQL Data Services, formerly known as SQL Server Data Services, provides databases in the cloud. As can be seen from the figure, this technology allows local and cloud-based applications to store and access data on Microsoft servers in Microsoft data centers. As with other cloud technologies, an organization only pays for what it uses. The use (and price) increases and decreases in accordance with the needs of the organization. Using databases in the cloud also allows you to convert what would be capital costs such as investments in hard drives or database management systems into operational costs.
The main objective of SQL Services is to be as accessible as possible. For this service makes available its interfaces through SOAP, and through REST, which allows you to access data in a variety of ways. And since data is available through standard protocols, SQL Data Services can be used on a wide variety of systems — it’s not just Windows technology.
Unlike Windows Azure storage services, SQL Data Services is built on Microsoft SQL Server. In spite of this, the service is not available through the usual relational interface. Instead, SQL Data Services provides a hierarchical data model that does not require a predefined data schema. Each data item in this service is stored as a property with its own name, type, and value. You can use REST or LINQ style queries to request this data.
Immediately the obvious question arises, why not just offer SQL Server in the cloud? Why instead provide a cloud-based database service that uses very different methods than the ones we are used to? One answer is that providing a little bit different from the usual set of services offers some advantages. SQL Data Services can provide greater scalability, availability and reliability than a simple DBMS launch in the cloud would give. The way in which new services organize and receive data makes replication and load balancing much easier and faster than with the usual relational way. Another advantage is that SQL Data Services does not pipe from clients to support their own DBMS. Instead of taking care of technical details, such as monitoring the use of hard disks, maintaining logs, determining the required number of instances, etc., SQL Data Services users can focus on the main thing - on data. In the end, Microsoft announced plans to add new relational capabilities to the SQL Data Service, so expect growth in their functionality.
SQL Data Services can be used in many different ways, here are some examples:
As with the other components of the Azure Service Platform, starting to use SQL Data Services is simple - you need to go to the portal and fill in the necessary information there. For cheap archival storage, providing data access to applications located in different places, or for other purposes, cloud databases can be a very attractive solution. With the advent of new technologies under the auspices of SQL Services, companies will be able to use the cloud for an increasing number of data-related tasks.
If the idea of ​​a cloud platform is relatively new, then the Internet is not at all new. Hundreds of millions of people around the world use it every day. To help them do this, Microsoft provides an ever-expanding set of web applications, including the Windows Live family of applications. These applications provide users with the ability to send instant messages, store contact information, receive payments and do other useful things.
All of these applications store data. Some of this data, such as contacts, is different for each user. Others, such as maps or search information, are, on the contrary, the same — the original data we all use is the same. In both cases, why not make this data available to other applications? Of course, control of access to data is required here - to freely distribute other people's personal data is not a good idea - but in general, using this data by other applications can often be a good idea.
In order to make this possible, Microsoft gathered all this diverse set of resources into one group - Live Services. Existing Microsoft applications, such as the Windows Live family, use Live Services to store and manage their data. To enable new applications to use this data, Microsoft provides the Live Framework. The main aspects are shown in fig. five.
Figure 5 The Live Framework provides applications with access to Live Services data, synchronizing this data between desktops and mobile devices if necessary.
The foundation of the Live Framework is the Live Operating Environment. As can be seen from the figure, this component runs in the cloud and applications access it through Live Services data. Data access occurs via HTTP, that is, any applications in .NET, Java, Java Script or other languages ​​can get access to Live Services data. Also, information from Live Services can be obtained through Atom or RSS, which allows applications to learn about changes to this data. The developer can use the Live Services Developer Portal web portal to configure and manage the Live Services features that a particular application needs.
Figure 5 also shows another aspect of the Live Framework - the Live Operating Environment, which can also run on systems with Windows Vista, Windows XP, Mac OS X, and Windows Mobile devices. To use this feature, the user groups the entire system into one piece, known as a mesh. For example, you can create a mesh that contains your desktop, laptop, and cellular. Each device will run an instance of the Live Operating Environment.
The most important feature of the mesh is that the Live Operating Environment synchronizes data between all the systems in it. Users and applications can specify which data should be synchronized, and the Live Operating Environment will automatically update all desktops, laptops and mobile devices included in the mesh, data that has been changed on one of the devices. And since the cloud is also part of any user mesh — it appears there as a special device — synchronization also works for Live Services data. For example, if a user stores his contacts in Windows Live Hotmail, Windows Live Messenger, or Windows Live Contacts, they will be synchronized between all devices in the mesh. (The truth is, in the November CTP Live Framework, this feature does not work yet). Through the Live Operating Environment you can also give access to some of your data to other users, which allows you to selectively share any information.
As the figure shows. 5., the application can access the mesh data through a local or cloud instance of the Live Operating Environment. In both cases, access is performed in the same way — via HTTP requests. Such uniformity of access allows the application to work equally regardless of whether there is a connection to the cloud, in any case, the data is available and you can access it in the same way.
Any application, whether it runs on Windows or another operating system, can access Live Services data in the cloud via the Live Operating Environment. If an application is running on a device that is part of the mesh, it can use the Live Operating Environment to access local copies of the Live Services data. There is a third possibility - a developer can do a thing called the Mesh-Enabled Web Application. Such applications are created using multi-platform technologies such as Silverlight and they access data through the Live Operating Environment. Due to these limitations, the Mesh-Enabled Web Application can potentially run on any user mesh machine - a Windows machine, Mac, Windows Mobile communicator, and it will always have access to the same synchronized data. To search for such applications, the Live Framework provides a cloud application — the mesh-enabled directory of web applications. The user can view the directory, select the application and install it. And to give application creators the opportunity to build a business on such applications, Microsoft plans to provide built-in support for displaying advertisements in their applications.
The Live Framework provides an easy way to access Live Services data (and this is not only contact information, as in the simplified examples given, but much more). Synchronization capabilities can also be applied in a variety of applications. For those applications that need these features, this platform offers a unique set of features.
The second part of the translation
Overview of the platform.
Using computers in the cloud can often be a very good idea. Instead of buying and maintaining your own hardware, why not use the mass of servers available and offered today via the Internet? For some applications, both code and data — both, can live in the cloud, where someone else maintains and maintains the systems they use. In other cases, applications that run inside the organization — local applications — can store their data in the cloud or use other infrastructure from the cloud. Applications running on desktops or mobile devices can use services in the cloud to synchronize data between different systems or for some other purpose.
In any case, whether the application itself works in the cloud or uses the services provided by the cloud, or both, you need something like a platform for such applications. Looking wider, under the platform for applications can be understood everything that provides the developer with a service for creating applications. For example, in the local Windows world, this includes technologies such as the .NET Framework, SQL Server, etc. For applications to use the cloud, there must be a cloud-based application platform. And since there are many different cloud applications for applications, different types of cloud platforms are useful in different situations.
The Microsoft Azure Service Platform is a group of cloud technologies, each of which provides a specific set of services for developers.
In Figure 1, the Azure Service Platform can be used both by applications running in the cloud and running on a local system.
Figure 1 The Azure Service Platform supports applications running both in the cloud and on the local system.
')
Platform components can be used by local applications running on different systems, including different versions of Windows, mobile devices, etc. These components include:
- Windows Azure: provides a Windows-based environment for running applications and storing data on servers in Microsoft data centers;
- Windows .NET Services: Provides distributed infrastructure services for cloud and local applications.
- Microsoft SQL Services: provides data services based on SQL Server.
- Live Services: Through the Live Framework provides access to data from applications on Microsoft Live. Live Framework also allows you to synchronize this data between desktops and devices, search and download applications and more.
Each component of the platform plays its own role. This review describes them all, first together at a high level, and then each in more detail. Although none of the components are yet to be released - the details and much more may change before the initial release - it is not too early to begin to deal with this new platform.
Windows Azure.
At a high level, understanding Windows Azure is quite simple: it is a platform for running windows-based applications and storing the data of these applications in the cloud. Figure 2 - its main components.
Figure 2 Windows Azure provides services for running and storing data to cloud applications.
As can be seen from the figure, Windows Azure runs on a large number of machines located in Microsoft data centers and accessible via the Internet. The Windows Azure Factory binds all this computing power into one. Windows Azure data storage and execution services are built on top of this factory.
Windows Azure run services are based, of course, on Windows. For the initial available version (CTP became available to the public in the fall of 2008), only applications based on the .Net Framework can be run on Windows Azure. The company announced plans to support unmanaged code as well, that is, applications not built on the .Net Framework in Windows Azure in 2009.
In the CTP version of Windows Azure, developers can create .Net-based applications, such as ASP.NET applications and WCF services. To do this, they can use C # or other .Net languages ​​along with traditional development tools like Visual Studio 2008. And although most developers will most likely use the original version of Windows Azure to create web applications, the platform also supports background processes, who work independently of the web part is not only a platform for web applications.
Both Windows Azure applications and local applications can use Windows Azure data storage services, in both cases in the same way — using a REST-type mechanism. However, the data storage used is not SQL Server. In particular, it is not even a relational system and its query language is not SQL. Since the storage system is designed to support applications on Windows Azure, it provides simpler, more scalable types of storage. Accordingly, it allows you to store large binary objects (blobs), provides queues for interaction between components of Windows Azure applications, and even something like tables with a regular query language.
Running applications and storing their data in the cloud can have obvious benefits. Instead of buying, installing and maintaining their own systems, an organization, for example, can pass on to a cloud service provider all these concerns. Also, customers only pay for the “computations” and storage they use, instead of serving a huge number of servers only for peak loads. And if the applications are written correctly, they will easily scale, taking advantage of the huge data centers provided by the service provider in the cloud.
However, obtaining these benefits requires proper management. In Windows Azure, each application has a configuration file - Fig. 2. By changing the information in this file, by hand or programmatically, the application owner can control various aspects of its behavior, such as the number of running Windows Azure instances. Window Azure Factory monitors the application to maintain a specified state.
To allow clients to create, configure, and monitor applications, Windows Azure provides a browser-accessible portal. The client provides his Windows Live ID, then chooses whether to create a hosting account for running applications or a storage account for storing data, or both. The application is free to choose the method of charging fees from its customers - a subscription, a fee for each use or something else.
Windows Azure is a common platform that can be used in various scenarios. Here are some examples based on what CTP allows:
- A startup that creates a new site, for example, a new VKontakte (in the original Facebook), can build its application on Windows Azure. Since the platform supports both Web-facing services and background processes, the application can provide both an interactive user interface and asynchronous work for users. Instead of spending time and money worrying about infrastructure, start-up participants can focus exclusively on creating code that is meaningful to their users and investors. The application can also start in a small size, requiring small expenses while it has few users. If the application “goes” and its use increases, Windows Azure will scale the application as needed.
- ISV (Independent SoftwareVendor), which creates a SaaS version of an existing local .Net application, can build it on Windows Azure. Since Windows Azure basically provides a standard .Net environment, migrating the business logic of an application to a cloud platform will not cause many problems. Again, developing on an existing platform will allow the ISV to focus on business logic — exactly what brings him money — instead of spending time on infrastructure.
- A corporation building an application for its customers can choose Windows Azure. Since Windows Azure is based on .Net, it will not be difficult to find suitable developers, and they will cost not “brutally” expensive. Running applications on Microsoft sites frees the corporation from the responsibility and cost of supporting its own north, turning capital costs into operational ones. Especially if the application has peaks of use - for example, if it is an online flower shop that is obliged to withstand the March 8 influx (in the original, Mother's Day), then allowing Microsoft to maintain a large server base for this can have a considerable economic effect.
Running applications in the cloud is one of the most important aspects of cloud computing. With Windows Azure, Microsoft provides a platform for running applications in the cloud, and ways to store application data.
Along with the growing interest in cloud computing, wait for more windows applications created for this new cloud world.
.Net Services.
Running applications in the cloud is an important part of cloud computing, but this is not all that is hidden under this term. You can also provide cloud-based services that can be used by either local or other cloud-based applications. The solution to this problem is the goal of .Net Services.
Initially known as BizTalk Services, .Net Services solve basic infrastructure problems when building distributed applications. Figure 3 - components.
Figure 3. .Net Services provides cloud infrastructure that can be used by both cloud and local applications.
Net Services Components:
- Access Control: An increasingly common way to identify when each user provides an application with a token containing a set of claims (claims). The application can now decide what is allowed to this user based on the provided assertions.
- Service Bus: Opening up access to local application services from the outside is harder than most people think. The goal of the service bus is to make it easier by opening the end points of the web services that will be available to other local or cloud applications. Each such access point is assigned a URI, which clients can use to discover and access the service. The service bus also solves the problems of working with NAT (Network Address Translation) and passing through firewalls without opening a new port for each application open to the outside.
- Workflow: Creating composite applications, such as applications for integrating enterprise applications, requires logic that coordinates the interaction between different parts of the system. Such logic is often best implemented at the expense of workflow, capable of supporting long-running processes. Built on top of the Windows Workflow Foundation, the Workflow service allows you to use this type of logic in the cloud.
Here are some examples of how .Net Services can be used:
- An ISV that provides an application used by clients in various organizations can use Access Control to simplify the development and operation of the application. For example, this .Net Services component can convert a variety of claims (claims) used in different client organizations, each of which uses different identification technologies, into a uniform set that the application being developed will use. It also allows you to move the identity federation to the Access Control service in the cloud, which frees the ISV from having to run its local federation software.
- Imagine a corporation wishing to give their trading partners access to one of their applications. It can open application functions via SOAP or REST web services, then register their endpoints in the Service Bus. Trading partners can now use the Service Bus to find and access these open services. Since this does not require the opening of new ports in the organization's firewall, this reduces the risk of opening access to the application. The organization can also use Access Control, which is designed to work with the Service Bus, to generalize the identity that customers send to the application.
- It is likely that the above business process, which includes the company's trading partners, should be carried out holistically. To do this, you can use Workflow services to implement a WF application that will manage the process. An application can interact with partners through the Service Bus and rely on Access Control in bringing the identification data to a common form.
As with Windows Azure, there is a portal available through a browser that allows customers to subscribe to .Net Services using Windows Live ID. Microsoft’s goal with their .Net Services is simple and straightforward: to provide a useful cloud infrastructure for distributed applications.
SQL Services
One of the most attractive ways to use servers available on the Internet is to work with data. Of course, this usually means providing a database engine, but not always the case is limited to this. The goal of SQL Services is to provide a set of cloud services for storing and working with a large variety of data types, from relational to unstructured.
Microsoft says that SQL Services will include various data services, such as reports, data analysis, etc. However, the very first component that came to light is SQL Data Services.
The idea is in fig. four.
Figure 4 SQL Services provides services for working with data in the cloud.
SQL Data Services, formerly known as SQL Server Data Services, provides databases in the cloud. As can be seen from the figure, this technology allows local and cloud-based applications to store and access data on Microsoft servers in Microsoft data centers. As with other cloud technologies, an organization only pays for what it uses. The use (and price) increases and decreases in accordance with the needs of the organization. Using databases in the cloud also allows you to convert what would be capital costs such as investments in hard drives or database management systems into operational costs.
The main objective of SQL Services is to be as accessible as possible. For this service makes available its interfaces through SOAP, and through REST, which allows you to access data in a variety of ways. And since data is available through standard protocols, SQL Data Services can be used on a wide variety of systems — it’s not just Windows technology.
Unlike Windows Azure storage services, SQL Data Services is built on Microsoft SQL Server. In spite of this, the service is not available through the usual relational interface. Instead, SQL Data Services provides a hierarchical data model that does not require a predefined data schema. Each data item in this service is stored as a property with its own name, type, and value. You can use REST or LINQ style queries to request this data.
Immediately the obvious question arises, why not just offer SQL Server in the cloud? Why instead provide a cloud-based database service that uses very different methods than the ones we are used to? One answer is that providing a little bit different from the usual set of services offers some advantages. SQL Data Services can provide greater scalability, availability and reliability than a simple DBMS launch in the cloud would give. The way in which new services organize and receive data makes replication and load balancing much easier and faster than with the usual relational way. Another advantage is that SQL Data Services does not pipe from clients to support their own DBMS. Instead of taking care of technical details, such as monitoring the use of hard disks, maintaining logs, determining the required number of instances, etc., SQL Data Services users can focus on the main thing - on data. In the end, Microsoft announced plans to add new relational capabilities to the SQL Data Service, so expect growth in their functionality.
SQL Data Services can be used in many different ways, here are some examples:
- An application can store old archived data in SQL Data Service. For example, imagine an application that provides frequently updated RSS feeds. Information that is older, say, 30 days, is unlikely to be requested frequently, but it should still be available. Transferring such data to the SQL Data Service can be a cheap and reliable alternative to their local storage.
- Imagine a manufacturer who wants to make information about their products available both to their dealer network and to customers directly. Storing such data in SQL Data Services will provide access to data for both applications that work for dealers and a web application for customers that works for the manufacturer itself. Since data is available through both REST and SOAP, applications that use this data can be written on different technologies and for different systems.
As with the other components of the Azure Service Platform, starting to use SQL Data Services is simple - you need to go to the portal and fill in the necessary information there. For cheap archival storage, providing data access to applications located in different places, or for other purposes, cloud databases can be a very attractive solution. With the advent of new technologies under the auspices of SQL Services, companies will be able to use the cloud for an increasing number of data-related tasks.
Live Services.
If the idea of ​​a cloud platform is relatively new, then the Internet is not at all new. Hundreds of millions of people around the world use it every day. To help them do this, Microsoft provides an ever-expanding set of web applications, including the Windows Live family of applications. These applications provide users with the ability to send instant messages, store contact information, receive payments and do other useful things.
All of these applications store data. Some of this data, such as contacts, is different for each user. Others, such as maps or search information, are, on the contrary, the same — the original data we all use is the same. In both cases, why not make this data available to other applications? Of course, control of access to data is required here - to freely distribute other people's personal data is not a good idea - but in general, using this data by other applications can often be a good idea.
In order to make this possible, Microsoft gathered all this diverse set of resources into one group - Live Services. Existing Microsoft applications, such as the Windows Live family, use Live Services to store and manage their data. To enable new applications to use this data, Microsoft provides the Live Framework. The main aspects are shown in fig. five.
Figure 5 The Live Framework provides applications with access to Live Services data, synchronizing this data between desktops and mobile devices if necessary.
The foundation of the Live Framework is the Live Operating Environment. As can be seen from the figure, this component runs in the cloud and applications access it through Live Services data. Data access occurs via HTTP, that is, any applications in .NET, Java, Java Script or other languages ​​can get access to Live Services data. Also, information from Live Services can be obtained through Atom or RSS, which allows applications to learn about changes to this data. The developer can use the Live Services Developer Portal web portal to configure and manage the Live Services features that a particular application needs.
Figure 5 also shows another aspect of the Live Framework - the Live Operating Environment, which can also run on systems with Windows Vista, Windows XP, Mac OS X, and Windows Mobile devices. To use this feature, the user groups the entire system into one piece, known as a mesh. For example, you can create a mesh that contains your desktop, laptop, and cellular. Each device will run an instance of the Live Operating Environment.
The most important feature of the mesh is that the Live Operating Environment synchronizes data between all the systems in it. Users and applications can specify which data should be synchronized, and the Live Operating Environment will automatically update all desktops, laptops and mobile devices included in the mesh, data that has been changed on one of the devices. And since the cloud is also part of any user mesh — it appears there as a special device — synchronization also works for Live Services data. For example, if a user stores his contacts in Windows Live Hotmail, Windows Live Messenger, or Windows Live Contacts, they will be synchronized between all devices in the mesh. (The truth is, in the November CTP Live Framework, this feature does not work yet). Through the Live Operating Environment you can also give access to some of your data to other users, which allows you to selectively share any information.
As the figure shows. 5., the application can access the mesh data through a local or cloud instance of the Live Operating Environment. In both cases, access is performed in the same way — via HTTP requests. Such uniformity of access allows the application to work equally regardless of whether there is a connection to the cloud, in any case, the data is available and you can access it in the same way.
Any application, whether it runs on Windows or another operating system, can access Live Services data in the cloud via the Live Operating Environment. If an application is running on a device that is part of the mesh, it can use the Live Operating Environment to access local copies of the Live Services data. There is a third possibility - a developer can do a thing called the Mesh-Enabled Web Application. Such applications are created using multi-platform technologies such as Silverlight and they access data through the Live Operating Environment. Due to these limitations, the Mesh-Enabled Web Application can potentially run on any user mesh machine - a Windows machine, Mac, Windows Mobile communicator, and it will always have access to the same synchronized data. To search for such applications, the Live Framework provides a cloud application — the mesh-enabled directory of web applications. The user can view the directory, select the application and install it. And to give application creators the opportunity to build a business on such applications, Microsoft plans to provide built-in support for displaying advertisements in their applications.
- Here are examples of various ways to use the Live Framework:
- A Java application running on Linux can use the Live Framework to work with user contacts. The application is not tied to any technology through which access to this data is open; all it works with is a permanent HTTP interface to user data.
- An application on .Net may require the user to create a mesh, and then use the Live Framework to cache and synchronize data. When the machine on which the application is running has an Internet connection, the application works with a copy of data in the cloud. When there is no connection — for example, when working on a laptop in an airplane — the application uses a local copy of the same data. Live Operating Environment. Replicates changes in local data to the cloud.
- ISV can make a Mesh-Enabled Web Application that allows users to find out what their friends are doing. This application can work without changes on all user devices, use different parts of the Live Framework for social applications. Since the Live Framework supports opening access to user data in a mesh via RSS, an application can, for example, subscribe and follow updates from any of the user's friends. Since the Live Framework provides a delivery mechanism for mesh-enabled web applications, it is possible that the application is “viral” when users invite their friends to use this application. And since in the mesh there is already data about the user's contacts from Live Services, the user can invite friends through the application itself simply by name, and the application itself will take care of delivering the invitation to friends.
The Live Framework provides an easy way to access Live Services data (and this is not only contact information, as in the simplified examples given, but much more). Synchronization capabilities can also be applied in a variety of applications. For those applications that need these features, this platform offers a unique set of features.
The second part of the translation
Source: https://habr.com/ru/post/50060/
All Articles