1 / 25

Occasionally Connected Smart Clients

cachet
Download Presentation

Occasionally Connected Smart Clients

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Occasionally Connected Smart Clients What is OCS Where are we going What can you do todayWhat is OCS Where are we going What can you do today

    2. What is: Occasionally Connected Components of an evolving application architecture Maximize the productivity of users by empowering them to leverage their computer, applications, data and files regardless of network availability Example: Outlook 2003

    3. Agenda Architecture evolution Future directions What you can do today Demo of SQL Server Everywhere Sync options for local storage

    4. Evolving Application Model

    5. Basic Components of An App Interaction Model User Interface Service (Web Service, CMD Line) Logic Security, rules, defaults, workflow Persistence Data (Database, XML, Data Device)

    6. MS Expense Owned by different teams and/or companies Version independently of each other Don’t necessarily know, or care, about each client Delegate responsibility to the next app / tier

    7. Fully Partitioned Applications Create complete components Delegate responsibility Empower decision making w/reference data & rules Communicate complete operations

    8. Where are we going… The future of Occasionally Connected Systems

    9. Occasionally Connected Systems OCS targets all Smart Client Platforms where we can assume the .NET Runtime is available. This includes desktop through Smart Phone Caching Applications that need to work offline need to take their resources with them. Typical LOB apps require various combinations of resources. Trying to put all resources into one bucket puts arbitrary limits on each solution. Trying to cache objects makes it difficult to aggregate information across various objects. If you have several Order objects, you may wind up with the same customer copied across several object graphs. Say you want to update the customer record; which object would you update? If you update a separate Customer Object then all Order Objects need to be re-cached to reflect the update. Instead the application can bring the relevant data partitioned for the specific user locally. It’s kept in relational form so the app can construct the object graph for the specific task. The customer can be updated and all orders locally would reflect the change. This is achieved with an embedded database that is lightweight, runs in-proc, can be click-once deployed when not available and spans all Microsoft operating systems from PocketPC to Desktop. Applications typical depend on files as well. Excel, Word, PPT, Pictures, etc. While these could be placed in a database, most applications can’t open a file from within a database. The same conflict detection and resolution rules apply to files as well as database entries. Applications may update files, or data, but they also interact with messaging services. An order may be placed in a queue for processing. Message caching enables the ability to cache non-queued messages. If a salesman travels to several locations during the week, the application can go out an pre-fetch maps and weather for each location. Then as the salesperson requests the information later that week, the result can be retrieved even though their laptop may not have connectivity. The message cache service caches responses based on the address and a selected set of parameters. The response would include the body of the message as well as any cache information such as when the item was cached and any expiration information. Application Updates enable the user to retrieve updates while the application is running. This is analogous to Windows Update running in the background, notifying the user with a balloon when an update is available. Background Tasks Each of these services may have multiple items. Since the goal for OCS is minimize the impact of transient networks, these services must be capable of operating independent of user interaction. Background Tasks are a set of components that enable a series of work items to function on a background thread. They are essentially a combination of the BackgroundWorker component, a Windows Services and Windows Workflow. Each BackgroundTasks has 1 or more steps that it executes. Long term these steps will be managed with Windows WorkFlow, however in this first release BackgroundTasks will support a collection of sequential steps. Once the steps have finished executing, the BackgroundTasks will sleep for a developer assigned period of time. This can be from seconds to days. The BackgroundTaks infrastructure will remember the time elapsed through application restarts and machine reboots. Similar to Outlook 2003, Background tasks are executed within the app-domain of the hosting application. BackgroundTasks will not execute when then application isn’t running, however the developer could write a windows services that also leverages BackgroundTasks. As BackgroundTasks execute, they can report progress up to the UI thread through a pattern similar to the BackgroundWorker ReportProgress API. Since BackgroundTasks will continually operate in a loop, they need the ability to Start, Pause and Stop. BackgroundTasks can also be triggered to start/stop based on a Network Resource coming available. In 2.0 a NetWork.IsAvailable event was added, however this event fires when any network is available, including plugging into an empty hub. Network Resource is a specific endpoint and gateway combination. Developers can configure Web Servers, UNC Shares, SQL Servers or any network address. They can also configure the type of gateway such as WiFi, Bluetooth, GPRS, etc. This enables the ability to choose the type of information they wish to sync based on the availability of a specific resource and the costs/bandwidth associated with the connection. To enable developer productivity, each Smart Client Platform will have a set of common/canned UI controls. These include ToolStrip Progress bars and ToolStrip MenuItems to monitor and configure BackgroundTasks. The developer can simply drop these on their designer surface and set the associated BackgroundTask with the property grid or Smart Tag. OCS targets all Smart Client Platforms where we can assume the .NET Runtime is available. This includes desktop through Smart Phone Caching Applications that need to work offline need to take their resources with them. Typical LOB apps require various combinations of resources. Trying to put all resources into one bucket puts arbitrary limits on each solution. Trying to cache objects makes it difficult to aggregate information across various objects. If you have several Order objects, you may wind up with the same customer copied across several object graphs. Say you want to update the customer record; which object would you update? If you update a separate Customer Object then all Order Objects need to be re-cached to reflect the update. Instead the application can bring the relevant data partitioned for the specific user locally. It’s kept in relational form so the app can construct the object graph for the specific task. The customer can be updated and all orders locally would reflect the change. This is achieved with an embedded database that is lightweight, runs in-proc, can be click-once deployed when not available and spans all Microsoft operating systems from PocketPC to Desktop. Applications typical depend on files as well. Excel, Word, PPT, Pictures, etc. While these could be placed in a database, most applications can’t open a file from within a database. The same conflict detection and resolution rules apply to files as well as database entries. Applications may update files, or data, but they also interact with messaging services. An order may be placed in a queue for processing. Message caching enables the ability to cache non-queued messages. If a salesman travels to several locations during the week, the application can go out an pre-fetch maps and weather for each location. Then as the salesperson requests the information later that week, the result can be retrieved even though their laptop may not have connectivity. The message cache service caches responses based on the address and a selected set of parameters. The response would include the body of the message as well as any cache information such as when the item was cached and any expiration information. Application Updates enable the user to retrieve updates while the application is running. This is analogous to Windows Update running in the background, notifying the user with a balloon when an update is available. Background Tasks Each of these services may have multiple items. Since the goal for OCS is minimize the impact of transient networks, these services must be capable of operating independent of user interaction. Background Tasks are a set of components that enable a series of work items to function on a background thread. They are essentially a combination of the BackgroundWorker component, a Windows Services and Windows Workflow. Each BackgroundTasks has 1 or more steps that it executes. Long term these steps will be managed with Windows WorkFlow, however in this first release BackgroundTasks will support a collection of sequential steps. Once the steps have finished executing, the BackgroundTasks will sleep for a developer assigned period of time. This can be from seconds to days. The BackgroundTaks infrastructure will remember the time elapsed through application restarts and machine reboots. Similar to Outlook 2003, Background tasks are executed within the app-domain of the hosting application. BackgroundTasks will not execute when then application isn’t running, however the developer could write a windows services that also leverages BackgroundTasks. As BackgroundTasks execute, they can report progress up to the UI thread through a pattern similar to the BackgroundWorker ReportProgress API. Since BackgroundTasks will continually operate in a loop, they need the ability to Start, Pause and Stop. BackgroundTasks can also be triggered to start/stop based on a Network Resource coming available. In 2.0 a NetWork.IsAvailable event was added, however this event fires when any network is available, including plugging into an empty hub. Network Resource is a specific endpoint and gateway combination. Developers can configure Web Servers, UNC Shares, SQL Servers or any network address. They can also configure the type of gateway such as WiFi, Bluetooth, GPRS, etc. This enables the ability to choose the type of information they wish to sync based on the availability of a specific resource and the costs/bandwidth associated with the connection. To enable developer productivity, each Smart Client Platform will have a set of common/canned UI controls. These include ToolStrip Progress bars and ToolStrip MenuItems to monitor and configure BackgroundTasks. The developer can simply drop these on their designer surface and set the associated BackgroundTask with the property grid or Smart Tag.

    10. Occasionally Connected Systems 8 minute demo8 minute demo

    11. How do I get there? What can I do today?

    12. Lots of toys (technologies)

    13. Isolate your components OCS targets all Smart Client Platforms where we can assume the .NET Runtime is available. This includes desktop through Smart Phone Caching Applications that need to work offline need to take their resources with them. Typical LOB apps require various combinations of resources. Trying to put all resources into one bucket puts arbitrary limits on each solution. Trying to cache objects makes it difficult to aggregate information across various objects. If you have several Order objects, you may wind up with the same customer copied across several object graphs. Say you want to update the customer record; which object would you update? If you update a separate Customer Object then all Order Objects need to be re-cached to reflect the update. Instead the application can bring the relevant data partitioned for the specific user locally. It’s kept in relational form so the app can construct the object graph for the specific task. The customer can be updated and all orders locally would reflect the change. This is achieved with an embedded database that is lightweight, runs in-proc, can be click-once deployed when not available and spans all Microsoft operating systems from PocketPC to Desktop. Applications typical depend on files as well. Excel, Word, PPT, Pictures, etc. While these could be placed in a database, most applications can’t open a file from within a database. The same conflict detection and resolution rules apply to files as well as database entries. Applications may update files, or data, but they also interact with messaging services. An order may be placed in a queue for processing. Message caching enables the ability to cache non-queued messages. If a salesman travels to several locations during the week, the application can go out an pre-fetch maps and weather for each location. Then as the salesperson requests the information later that week, the result can be retrieved even though their laptop may not have connectivity. The message cache service caches responses based on the address and a selected set of parameters. The response would include the body of the message as well as any cache information such as when the item was cached and any expiration information. Application Updates enable the user to retrieve updates while the application is running. This is analogous to Windows Update running in the background, notifying the user with a balloon when an update is available. Background Tasks Each of these services may have multiple items. Since the goal for OCS is minimize the impact of transient networks, these services must be capable of operating independent of user interaction. Background Tasks are a set of components that enable a series of work items to function on a background thread. They are essentially a combination of the BackgroundWorker component, a Windows Services and Windows Workflow. Each BackgroundTasks has 1 or more steps that it executes. Long term these steps will be managed with Windows WorkFlow, however in this first release BackgroundTasks will support a collection of sequential steps. Once the steps have finished executing, the BackgroundTasks will sleep for a developer assigned period of time. This can be from seconds to days. The BackgroundTaks infrastructure will remember the time elapsed through application restarts and machine reboots. Similar to Outlook 2003, Background tasks are executed within the app-domain of the hosting application. BackgroundTasks will not execute when then application isn’t running, however the developer could write a windows services that also leverages BackgroundTasks. As BackgroundTasks execute, they can report progress up to the UI thread through a pattern similar to the BackgroundWorker ReportProgress API. Since BackgroundTasks will continually operate in a loop, they need the ability to Start, Pause and Stop. BackgroundTasks can also be triggered to start/stop based on a Network Resource coming available. In 2.0 a NetWork.IsAvailable event was added, however this event fires when any network is available, including plugging into an empty hub. Network Resource is a specific endpoint and gateway combination. Developers can configure Web Servers, UNC Shares, SQL Servers or any network address. They can also configure the type of gateway such as WiFi, Bluetooth, GPRS, etc. This enables the ability to choose the type of information they wish to sync based on the availability of a specific resource and the costs/bandwidth associated with the connection. To enable developer productivity, each Smart Client Platform will have a set of common/canned UI controls. These include ToolStrip Progress bars and ToolStrip MenuItems to monitor and configure BackgroundTasks. The developer can simply drop these on their designer surface and set the associated BackgroundTask with the property grid or Smart Tag. OCS targets all Smart Client Platforms where we can assume the .NET Runtime is available. This includes desktop through Smart Phone Caching Applications that need to work offline need to take their resources with them. Typical LOB apps require various combinations of resources. Trying to put all resources into one bucket puts arbitrary limits on each solution. Trying to cache objects makes it difficult to aggregate information across various objects. If you have several Order objects, you may wind up with the same customer copied across several object graphs. Say you want to update the customer record; which object would you update? If you update a separate Customer Object then all Order Objects need to be re-cached to reflect the update. Instead the application can bring the relevant data partitioned for the specific user locally. It’s kept in relational form so the app can construct the object graph for the specific task. The customer can be updated and all orders locally would reflect the change. This is achieved with an embedded database that is lightweight, runs in-proc, can be click-once deployed when not available and spans all Microsoft operating systems from PocketPC to Desktop. Applications typical depend on files as well. Excel, Word, PPT, Pictures, etc. While these could be placed in a database, most applications can’t open a file from within a database. The same conflict detection and resolution rules apply to files as well as database entries. Applications may update files, or data, but they also interact with messaging services. An order may be placed in a queue for processing. Message caching enables the ability to cache non-queued messages. If a salesman travels to several locations during the week, the application can go out an pre-fetch maps and weather for each location. Then as the salesperson requests the information later that week, the result can be retrieved even though their laptop may not have connectivity. The message cache service caches responses based on the address and a selected set of parameters. The response would include the body of the message as well as any cache information such as when the item was cached and any expiration information. Application Updates enable the user to retrieve updates while the application is running. This is analogous to Windows Update running in the background, notifying the user with a balloon when an update is available. Background Tasks Each of these services may have multiple items. Since the goal for OCS is minimize the impact of transient networks, these services must be capable of operating independent of user interaction. Background Tasks are a set of components that enable a series of work items to function on a background thread. They are essentially a combination of the BackgroundWorker component, a Windows Services and Windows Workflow. Each BackgroundTasks has 1 or more steps that it executes. Long term these steps will be managed with Windows WorkFlow, however in this first release BackgroundTasks will support a collection of sequential steps. Once the steps have finished executing, the BackgroundTasks will sleep for a developer assigned period of time. This can be from seconds to days. The BackgroundTaks infrastructure will remember the time elapsed through application restarts and machine reboots. Similar to Outlook 2003, Background tasks are executed within the app-domain of the hosting application. BackgroundTasks will not execute when then application isn’t running, however the developer could write a windows services that also leverages BackgroundTasks. As BackgroundTasks execute, they can report progress up to the UI thread through a pattern similar to the BackgroundWorker ReportProgress API. Since BackgroundTasks will continually operate in a loop, they need the ability to Start, Pause and Stop. BackgroundTasks can also be triggered to start/stop based on a Network Resource coming available. In 2.0 a NetWork.IsAvailable event was added, however this event fires when any network is available, including plugging into an empty hub. Network Resource is a specific endpoint and gateway combination. Developers can configure Web Servers, UNC Shares, SQL Servers or any network address. They can also configure the type of gateway such as WiFi, Bluetooth, GPRS, etc. This enables the ability to choose the type of information they wish to sync based on the availability of a specific resource and the costs/bandwidth associated with the connection. To enable developer productivity, each Smart Client Platform will have a set of common/canned UI controls. These include ToolStrip Progress bars and ToolStrip MenuItems to monitor and configure BackgroundTasks. The developer can simply drop these on their designer surface and set the associated BackgroundTask with the property grid or Smart Tag.

    14. Categorizing Techno Gadgets

    15. Occasionally Connected Sync

    16. Categorizing Techno Gadgets

    17. Slide 15 – From Vision To Reality (roadmap) – SQL Everywhere announce Today’s workforce is increasingly mobile and having the right data, in the right form, at the right place in the right time is crucial to effectiveness. This will require a new generation of application architecture. Applications are increasingly mobile and occasionally connected, so they need sophisticated data management and synchronization capabilities to integrate with distributed systems and provide the right data in the right form on the right system for the job. To enable our customers to build these types of applications I am pleased to announce today a new addition to the SQL Server family, SQL Server Everywhere Edition. SQL Everywhere is a designed to meet the needs of today’s distributed information requirements. SQL Everywhere is a member of the SQL Server data platform family and provides a lightweight, compact, but rich subset of the capabilities found in other SQL Server editions. SQL Everywhere also employs a common programming model through ADO.Net in the .Net Framework and .Net Compact Framework so that developers who are familiar with building applications for other SQL Server editions will immediately be productive on SQL Everywhere. Beyond having rich local data management capabilities, SQL Everywhere will also include support for seamlessly synchronizing with other SQL Server editions and provides features that promote building rich client applications that operate effectively in today’s increasingly “occasionally connected” environment. This new member of the SQL Server family will not only be ideal for ISVs who need a lightweight, portable, and private data store for their applications, but also especially useful for certain types of applications, such as field service applications, such as the application used by FedEx for their mobile delivery tracking system. These applications are characterized by having a set of reference data, such as customer lists or product item data, a partitioned set of other data such accounts, plan data such as a visit list for a visiting nurse. All of these applications generate data in a disconnected semi-connected fashion like collection of inventory data during a replenishment route. Data generated by the field professional is synchronized as soon as connectivity can be established. Can also mention that SQL Server Everywhere replaces SQL Mobile. Slide 15 – From Vision To Reality (roadmap) – SQL Everywhere announce Today’s workforce is increasingly mobile and having the right data, in the right form, at the right place in the right time is crucial to effectiveness. This will require a new generation of application architecture. Applications are increasingly mobile and occasionally connected, so they need sophisticated data management and synchronization capabilities to integrate with distributed systems and provide the right data in the right form on the right system for the job. To enable our customers to build these types of applications I am pleased to announce today a new addition to the SQL Server family, SQL Server Everywhere Edition. SQL Everywhere is a designed to meet the needs of today’s distributed information requirements. SQL Everywhere is a member of the SQL Server data platform family and provides a lightweight, compact, but rich subset of the capabilities found in other SQL Server editions. SQL Everywhere also employs a common programming model through ADO.Net in the .Net Framework and .Net Compact Framework so that developers who are familiar with building applications for other SQL Server editions will immediately be productive on SQL Everywhere. Beyond having rich local data management capabilities, SQL Everywhere will also include support for seamlessly synchronizing with other SQL Server editions and provides features that promote building rich client applications that operate effectively in today’s increasingly “occasionally connected” environment. This new member of the SQL Server family will not only be ideal for ISVs who need a lightweight, portable, and private data store for their applications, but also especially useful for certain types of applications, such as field service applications, such as the application used by FedEx for their mobile delivery tracking system. These applications are characterized by having a set of reference data, such as customer lists or product item data, a partitioned set of other data such accounts, plan data such as a visit list for a visiting nurse. All of these applications generate data in a disconnected semi-connected fashion like collection of inventory data during a replenishment route. Data generated by the field professional is synchronized as soon as connectivity can be established. Can also mention that SQL Server Everywhere replaces SQL Mobile.

    18. 7 minute demo7 minute demo

    19. Local Database Options Slide demonstrates how we would position SQL Express compared to SQL Mobile. Currently we support SQL Mobile on the Tablet PC platform. By removing the Tablet PC restriction we can align SQL Mobile with our single user scenarios compared to SQL Express which focused on multi-user scenarios. Technically, SQL Mobile does support multiple connections, however, this is designed for UI and background sync operations. It not designed as a multi-user, enterprise scaling database. When you need an embedded database with a subset of the functionality from SQL Server, SQL Mobile is for you. When you’re developing enterprise applications that share a common database on a server, SQL Express, or one of the upper SQL Sku’s is for you. If you need high end analytics, extremely complex processing and are willing to dedicate more resources to the database, SQL Express can be leveraged as your local store as well. The benefits of SQL Mobile is it’s a no-brainer to deploy and use. No longer do you have to make the tough trade offs between XML which is on every desktop and SQL Express which requires an Admin install and requires heavier machine resources.Slide demonstrates how we would position SQL Express compared to SQL Mobile. Currently we support SQL Mobile on the Tablet PC platform. By removing the Tablet PC restriction we can align SQL Mobile with our single user scenarios compared to SQL Express which focused on multi-user scenarios. Technically, SQL Mobile does support multiple connections, however, this is designed for UI and background sync operations. It not designed as a multi-user, enterprise scaling database. When you need an embedded database with a subset of the functionality from SQL Server, SQL Mobile is for you. When you’re developing enterprise applications that share a common database on a server, SQL Express, or one of the upper SQL Sku’s is for you. If you need high end analytics, extremely complex processing and are willing to dedicate more resources to the database, SQL Express can be leveraged as your local store as well. The benefits of SQL Mobile is it’s a no-brainer to deploy and use. No longer do you have to make the tough trade offs between XML which is on every desktop and SQL Express which requires an Admin install and requires heavier machine resources.

    20. Categorizing Techno Gadgets

    21. Synchronization Options philipphilip

    22. RDA Sync OCS targets all Smart Client Platforms where we can assume the .NET Runtime is available. This includes desktop through Smart Phone Caching Applications that need to work offline need to take their resources with them. Typical LOB apps require various combinations of resources. Trying to put all resources into one bucket puts arbitrary limits on each solution. Trying to cache objects makes it difficult to aggregate information across various objects. If you have several Order objects, you may wind up with the same customer copied across several object graphs. Say you want to update the customer record; which object would you update? If you update a separate Customer Object then all Order Objects need to be re-cached to reflect the update. Instead the application can bring the relevant data partitioned for the specific user locally. It’s kept in relational form so the app can construct the object graph for the specific task. The customer can be updated and all orders locally would reflect the change. This is achieved with an embedded database that is lightweight, runs in-proc, can be click-once deployed when not available and spans all Microsoft operating systems from PocketPC to Desktop. Applications typical depend on files as well. Excel, Word, PPT, Pictures, etc. While these could be placed in a database, most applications can’t open a file from within a database. The same conflict detection and resolution rules apply to files as well as database entries. Applications may update files, or data, but they also interact with messaging services. An order may be placed in a queue for processing. Message caching enables the ability to cache non-queued messages. If a salesman travels to several locations during the week, the application can go out an pre-fetch maps and weather for each location. Then as the salesperson requests the information later that week, the result can be retrieved even though their laptop may not have connectivity. The message cache service caches responses based on the address and a selected set of parameters. The response would include the body of the message as well as any cache information such as when the item was cached and any expiration information. Application Updates enable the user to retrieve updates while the application is running. This is analogous to Windows Update running in the background, notifying the user with a balloon when an update is available. Background Tasks Each of these services may have multiple items. Since the goal for OCS is minimize the impact of transient networks, these services must be capable of operating independent of user interaction. Background Tasks are a set of components that enable a series of work items to function on a background thread. They are essentially a combination of the BackgroundWorker component, a Windows Services and Windows Workflow. Each BackgroundTasks has 1 or more steps that it executes. Long term these steps will be managed with Windows WorkFlow, however in this first release BackgroundTasks will support a collection of sequential steps. Once the steps have finished executing, the BackgroundTasks will sleep for a developer assigned period of time. This can be from seconds to days. The BackgroundTaks infrastructure will remember the time elapsed through application restarts and machine reboots. Similar to Outlook 2003, Background tasks are executed within the app-domain of the hosting application. BackgroundTasks will not execute when then application isn’t running, however the developer could write a windows services that also leverages BackgroundTasks. As BackgroundTasks execute, they can report progress up to the UI thread through a pattern similar to the BackgroundWorker ReportProgress API. Since BackgroundTasks will continually operate in a loop, they need the ability to Start, Pause and Stop. BackgroundTasks can also be triggered to start/stop based on a Network Resource coming available. In 2.0 a NetWork.IsAvailable event was added, however this event fires when any network is available, including plugging into an empty hub. Network Resource is a specific endpoint and gateway combination. Developers can configure Web Servers, UNC Shares, SQL Servers or any network address. They can also configure the type of gateway such as WiFi, Bluetooth, GPRS, etc. This enables the ability to choose the type of information they wish to sync based on the availability of a specific resource and the costs/bandwidth associated with the connection. To enable developer productivity, each Smart Client Platform will have a set of common/canned UI controls. These include ToolStrip Progress bars and ToolStrip MenuItems to monitor and configure BackgroundTasks. The developer can simply drop these on their designer surface and set the associated BackgroundTask with the property grid or Smart Tag. OCS targets all Smart Client Platforms where we can assume the .NET Runtime is available. This includes desktop through Smart Phone Caching Applications that need to work offline need to take their resources with them. Typical LOB apps require various combinations of resources. Trying to put all resources into one bucket puts arbitrary limits on each solution. Trying to cache objects makes it difficult to aggregate information across various objects. If you have several Order objects, you may wind up with the same customer copied across several object graphs. Say you want to update the customer record; which object would you update? If you update a separate Customer Object then all Order Objects need to be re-cached to reflect the update. Instead the application can bring the relevant data partitioned for the specific user locally. It’s kept in relational form so the app can construct the object graph for the specific task. The customer can be updated and all orders locally would reflect the change. This is achieved with an embedded database that is lightweight, runs in-proc, can be click-once deployed when not available and spans all Microsoft operating systems from PocketPC to Desktop. Applications typical depend on files as well. Excel, Word, PPT, Pictures, etc. While these could be placed in a database, most applications can’t open a file from within a database. The same conflict detection and resolution rules apply to files as well as database entries. Applications may update files, or data, but they also interact with messaging services. An order may be placed in a queue for processing. Message caching enables the ability to cache non-queued messages. If a salesman travels to several locations during the week, the application can go out an pre-fetch maps and weather for each location. Then as the salesperson requests the information later that week, the result can be retrieved even though their laptop may not have connectivity. The message cache service caches responses based on the address and a selected set of parameters. The response would include the body of the message as well as any cache information such as when the item was cached and any expiration information. Application Updates enable the user to retrieve updates while the application is running. This is analogous to Windows Update running in the background, notifying the user with a balloon when an update is available. Background Tasks Each of these services may have multiple items. Since the goal for OCS is minimize the impact of transient networks, these services must be capable of operating independent of user interaction. Background Tasks are a set of components that enable a series of work items to function on a background thread. They are essentially a combination of the BackgroundWorker component, a Windows Services and Windows Workflow. Each BackgroundTasks has 1 or more steps that it executes. Long term these steps will be managed with Windows WorkFlow, however in this first release BackgroundTasks will support a collection of sequential steps. Once the steps have finished executing, the BackgroundTasks will sleep for a developer assigned period of time. This can be from seconds to days. The BackgroundTaks infrastructure will remember the time elapsed through application restarts and machine reboots. Similar to Outlook 2003, Background tasks are executed within the app-domain of the hosting application. BackgroundTasks will not execute when then application isn’t running, however the developer could write a windows services that also leverages BackgroundTasks. As BackgroundTasks execute, they can report progress up to the UI thread through a pattern similar to the BackgroundWorker ReportProgress API. Since BackgroundTasks will continually operate in a loop, they need the ability to Start, Pause and Stop. BackgroundTasks can also be triggered to start/stop based on a Network Resource coming available. In 2.0 a NetWork.IsAvailable event was added, however this event fires when any network is available, including plugging into an empty hub. Network Resource is a specific endpoint and gateway combination. Developers can configure Web Servers, UNC Shares, SQL Servers or any network address. They can also configure the type of gateway such as WiFi, Bluetooth, GPRS, etc. This enables the ability to choose the type of information they wish to sync based on the availability of a specific resource and the costs/bandwidth associated with the connection. To enable developer productivity, each Smart Client Platform will have a set of common/canned UI controls. These include ToolStrip Progress bars and ToolStrip MenuItems to monitor and configure BackgroundTasks. The developer can simply drop these on their designer surface and set the associated BackgroundTask with the property grid or Smart Tag.

    23. SQL Everywhere Sync Options 8 minute demo8 minute demo

    24. Merge Replication

    25. Wrapping up Evolve your apps to your users needs Compose your app into smaller, complete units Continue developing services Isolate data entities, storage, sync and transport Start with SQL Mobile ? SQL Everywhere Deliver compelling end user scenarios that enable your users

    26. Additional Info OCS Info, SQL Everywhere Q&A http://blogs.msdn.com/SteveLasker Info about SQL Mobile http://www.microsoft.com/SqlMobile Data Designer Info http://blogs.msdn.com/SmartClientData

More Related