Sybase Unwired Platform Version 2.0

Transcription

1 white paper Sybase Unwired Platform Version 2.0 Architecture

2 TABLE OF CONTENTS 1 Introduction 1 Overview of the Sybase Unwired Platform 2 Basic Development and Deployment Process 3 Common Elements of the Architecture 3 Network Topology 4 Administration and Monitoring 4 Device Services 5 Hybrid Web Container Applications 6 Container Messaging Components 7 Mobile Workflow Enablement 7 Workflow Components 8 Mobile Synchronization Applications 8 Cache Synchronization 9 Cache Synchronization Components 11 Synchronization with Data Orchestration Engine 12 Data Orchestration Engine Components 13 Summary

3 Introduction This document is designed for service providers and enterprises that plan to deploy the Sybase Unwired Platform (SUP) and need to gain a functional understanding of the technology so that they can make informed decisions in choosing the correct mobile technology to use for a particular use case. In addition, a level of detail is provided to help administrators gain insight into the internal workings of the platform. This document serves as a foundation for other, more specific explanations of particular technical aspects of the system, such as sizing, performance and tuning, security or Data Orchestration Engine (DOE) in-depth architecture. Developers may also find it useful to consult material specifically related to development fundamentals or tutorials. Overview of the Sybase Unwired Platform Individuals and businesses develop mobile applications for specific user needs ranging from teams of service workers who use ruggedized devices for industry-specific applications to consultants who track time and expenses on a mobile device or perform simple corporate approvals. SUP provides capabilities that support these mobile scenarios as well as cross-industry applications, such as customer relationship management (CRM), human resources, supply chain management, business intelligence, product lifecycle management and industry-specific applications tailored for the service provider, chemical/pharmaceutical and utilities industries. SUP s primary value proposition is in serving as an information bridge between the device user and the enterprise data that is secured behind the corporate firewall or hosted in a cloud infrastructure. The platform, as mobile middleware, has a range of components hosted within the enterprise and on the device, as shown in Figure 1. These platform technologies are hosted under a common design, runtime and management infrastructure that provides the following features: Connectivity to multiple client device types and mobile operating systems Support for native client, object-based APIs based on the device platform language Support for mobile Web-based clients within a secure enterprise sandbox Eclipse-based visual development tooling for building mobile data services and generating device-side data persistence APIs Enterprise mobilization architecture that uses standard and proprietary interfaces to support a variety of enterprise data resources End-to-end pluggable security that extends from the enterprise to devices Support for mobile users who are either occasionally connected or who work entirely online Push notifications that alert clients to refresh their mobile view of the data Unified platform administration and monitoring Connect Heterogeneous data sources Create Eclipse Consume Heterogeneous mobile devices Databases Sybase Unwired Platform Android (Mobile Workflow only) BlackBerry Web Services Software Applications Mobile Business Objects Workflows Native Applications iphone ipad Windows Windows Mobile Management Console Figure 1. Platform Overview Control Device and server management and security 1

4 One or more of these technologies come together to provide solution support for a few major types of mobile applications: Hybrid Web Container applications Simple cross-platform request/reply or lookup Mobile workflow enablement Native applications using synchronization Result set cache synchronization in an SUP stand-alone mode Data consolidation and distribution with the DOE The purpose and function of the major application pillars is described in more detail later in this document, alongside the major technology components that support them. Basic Development and Deployment Process In all but the DOE application, the developer starts the process of building an application by using Eclipse-based tooling to discover assets of enterprise data sources and tailor the mobile interaction pattern (usually involving the selection of data subsets) for mobilization. The most significant model artifacts are Mobile Business Objects (MBOs), which describe the interaction with the back-end data and the device-side data representation. The MBO is a middleware object that describes mobile data and operations on that data. The operations on an MBO are typically CRUD related. Changes made to an MBO on the device are reflected in the back end and then communicated to the user by updating MBO data on the devices. Using the Eclipse tooling and the MBO model, a developer creates a package containing one or more MBOs that can be deployed into the server runtime environment. Each package is assigned a version that is associated with the specific runtime artifacts generated by the deployment architecture (see Figure 2). When using the DOE style of application, the developer starts by describing back-end interaction and the application content model within the DOE tooling. The result of this design activity is a package that can be deployed, via command line tools, into the SUP server where artifacts are generated for store and forwarding of messages between server and device. Sybase Unwired Platform Development Workflow Develop Mobile Model from Enterprise Content Publish in Unwired Server Generate Device Artifacts Develop Device Application Test on Emulator and/or Device Figure 2. Development Paradigm Once the mobile package is deployed, the developer can generate device-side artifacts that form the basis of the mobile application interactions with the SUP services and data. One or more packages can be used within a single application. The same package version information is embedded in the device-side artifacts and is used to mate the device application with the correct runtime package. The specific development details of different application types vary; see the developer-specific guides for more information. 2

5 Common Elements of the Architecture Network Topology The majority of the platform infrastructure is installed alongside other corporate assets while an externally facing mobile data channel, the Relay Server, is installed in the DMZ (see Figure 3). The Relay Server runs as a plug-in to either an Apache Web server or Microsoft Internet Information Server (IIS). The Relay Server is a single point of contact for devices and is a specialized reverse proxy that avoids opening inbound ports in the firewall to the SUP server 1. A Relay Server Outbound Enabler (RSOE) opens a bidirectional communication channel from inside the firewall outward to the Relay Server. This communication channel allows devices to communicate with the Unwired Server over one of several ports depending on the specific purpose and technology. These connectivity services include facilities for the two principal device-to-server transport technologies: Secure mobile messaging channel for reliable data transport and server-side notifications Sybase MobiLink technology used for efficient bulk data replication All of the associated ports are configurable upon installation or within the administrative interfaces of the Sybase Control Center (SCC). Note that as of this version the platform-specific notification facilities provided by the device manufacturers do not conform to the Relay Server semantics (your IT department must allocate an outbound port for APNS, BES and others.). Sybase Afaria technology is used to deploy device applications and help configure, manage and secure those applications and certain enterprise data on devices. The Afaria technology interacts with the device platform s local management facilities on the device to enforce enterprise policies. For some platforms, Afaria also offers an enterprise application store as an alternative to consumer-facing facilities. Internal Network External Network Unwired WorkSpace (Eclipse) Internal Firewall DMZ External Firewall Unwired Server SCC Admin Console Relay Server Afaria Server HTTP/S HTTP/S Figure 3. Network Topology The following sections describe technology-specific SUP usage patterns and provide a general discussion of the architecture. 1 Relay Sever is an optional component that may be replaced by other third-party proxy technologies or firewall management techniques 3

6 Administration and Monitoring The Unified Agent Service (UAS) acts as a central control and process monitoring facility for all Sybase server technology (not to be confused with application monitoring, which is done in the core server stack). This JMX-based agent has an embedded Web server to which the SCC communicates and an associated database for managing its own control and alerting metadata (see Figure 4). Sybase Control Center SOAP RPC Client Distributed Level RMI Connector HTML Adapter SOAP-RPC Adapter Agent Level MBean Server JMX Service Beans Timer, Monitoring, Etc. UA Service Beans Security, Sessions, File Transfer, RemoteShell, Discovery, Messaging, Etc. Discovery Service Beans UDP, Jini, LDAP Instrumentation Level SQL Anywhere Sybase Servers Unwired Servers Figure 4. Management Infrastructure From an administrative standpoint, there are several functional hierarchies: The server or cluster level managed by a host administrator who has global control over the runtime infrastructure and performance tuning parameters The domain level associated with a pluggable security authority. The domain can be used for implementing multi-tenancy within a single server runtime. Each domain has an associated administrator. The application level within the domain. Applications consist of packages that are associated with a security template. Packages are deployed to the server within an administrative domain Logging policies can be applied separately at the domain and package level. Monitoring can be configured to record various application behaviors including device requests and application statistics. These records are written asynchronously to the monitoring database. Sybase recommends isolating this database on its own hardware if a significant amount of monitoring is turned on during production on medium to large deployments. Device Services As an information bridge between the enterprise back-end and the device, SUP provides several key features that make developing applications much easier and more secure. Moving data securely and efficiently is one of the key value propositions of the platform. SUP uses two proprietary technologies to provide the best quality of service with regard to efficiency and seamless integration with the data store. Two main types of device applications Hybrid Web Container and native applications are available. The device stack supports a messaging protocol for devices built on the Hybrid Web Container, and the SUP DOE application approach supports native device applications with rule distribution (see Figure 5). Native applications built without DOE utilize Sybase MobiLink technology to replicate data to the Sybase UltraLite database. 4

7 Hybrid Web Container MBO SDK Browser Runtime Application JavaScript Container API XML Cache Native Interface Native Application Objects Object API Security (Data Vault, SSO,...) Notification Messaging API Sync API Message Database UltraLite Database Figure 5. Device Stack Security features are embedded into the Software Development Kit (SDK) to support secure storage of certificates, use of these artifacts in authentication such as single sign-on (X.509 and SSO2 logon ticket) and other features related to encryption of the database. APIs for Certificate store, logon certificates and the data vault are also available. Each device application type makes use of the same set of security features. Hybrid Web Container Applications SUP Hybrid Web Container bridges the deficiencies of today s Mobile Web Browsers with the power of device OS services such as GeoLocation and others. Developers can build rich applications using Web technologies and add functionality similar to what is available in today s native applications. In SUP 2.0, the Hybrid Web Container is a complete rewrite of the client-side container technology available in previous versions that was based on proprietary client-side application definition (XML) used to render the application interface within the container. Typical use cases for Hybrid Web Container technology include mobile workflows, lightweight applications and so on. Most of these applications have the following characteristics: Low data volume Simple user experience No long-lasting, offline, stateful transactions Simple business logic The Hybrid Web Container supports three basic patterns. In many applications, a combination of these patterns is applied to implement the use case. Notifications Also referred to as server initiated, actions performed in the back-end by external applications in the context of a business process, resulting in mobile users being notified with information. Lookup Mobile users take action on devices to request information from the back-end. Action/Decision Forms Users take action on devices to submit a form, make a decision and so on resulting in some enterprise business process state transition. 5

8 The Hybrid Web Container is the runtime on the device within which these patterns are executed. The applications formed from these patterns are referred to as mobile workflows in the context of SUP 2.0. Technically workflow is a specific use case of the general technology. The Hybrid Web Container is a native application with an embedded browser that allows developers to build applications with the simplicity of Web development but utilize the power of native device services. SUP 2.0 delivers a native application for ios, Android, Windows Mobile and BlackBerry platforms. In addition to the standard Web browser capabilities that can be availed by using standard HTML/CSS/JS code, the Hybrid Web Container also provides additional device and SUP services, including: Off-line cache Reliable messaging Secure store Application provisioning Integration with SUP middleware for MBO data exchange In future versions, other device services such as camera, contacts, and others will be supported. Container Messaging Components Hybrid Web Container Device Runtime This device-resident native application provides a runtime environment for the Hybrid Web applications, and it has to be deployed once using an application provisioning tool such as Afaria. After that, the applications are deployed automatically when the container runs on the device and the protocol between container and server identify differences in versions (see Figure 6). Container App Designer MBO Tooling Container Client Metadata (HTML/CSS/JS) Browser Container Metadata (HTML5/CSS/JS) Workflow Server Metadata Unwired Server MBO Metadata Lookup/Search Container Services (Storage/Messaging/ Security/Provisioning) MBO Cache Pull Hybrid Web Container Push/DCN SAP System XML Messages Figure 6. Mobile Workflow Forms Editor 6

9 Mobile Workflow Forms Editor Mobile Workflow Forms Editor is the WYSIWYG tool to build lightweight applications and mobile workflows that run in the Hybrid Web Container. The Mobile Workflow Forms Editor, included with Sybase Unwired Platform, helps design the user interface and test the flow of the business process for a Hybrid Web Container application. The Mobile Workflow Forms Editor allows the development of mobile workflow screens that can call create, update and delete operations, as well as object queries, of a mobile business object. Mobile Workflow package files are generated using the package generation wizard in the Mobile Workflow Forms Editor. The generated package output is comprised of HTML/CSS/JavaScript. The logic for accessing the data and navigating between screens is exposed as a JavaScript API. Packages can be deployed to Unwired Server and assigned to users using the Mobile Workflow Forms Editor in Eclipse through a connection to the SCC administrative interfaces. The generated Hybrid Web Container package contains files that reference an MBO package, an MBO in that package and the operation or object query to call along with a mapping of which key values map to parameter values. Middleware This architecture relies on SUP middleware to integrate and mobilize data sources using the core SUP modeling concept called MBO. Middleware provides connectivity to various back- ends through this intermediate MBO runtime construct, thereby providing a single interface for device application developers and abstracting the complexity of the back-end. It also provisions the hybrid container applications based on the application assignments in a secure fashion. The communication between the container and middleware is encrypted to enable confidentiality of message content. Sybase Unwired Workspace Mobile Business Object Tooling This component is a key piece of the architecture that enables modeling MBOs, which are used for data transfer between the container and the back-end through the middleware. This component is an Eclipse plug-in just like the Mobile Workflow Forms Editor. Administration Console Hybrid Web Container applications are managed and deployed through the same management/administration console used to manage SUP. This consistency provides the ability to assign applications to devices/users based on regular expression-centric matching rules. This console also enables monitoring of the state of the platform and provides metrics for tuning. Mobile Workflow Enablement Sybase Mobile Workflow technologies enable mobile device users to operate as workflow participants. SUP provides the last-mile connectivity for workflow applications, allowing the mobile user to start and respond to back-end enterprise requests within a generic framework. Mobile Workflow utilizes the concept of a container on the device that is a native application with a Web browser plug-in, a built-in SDK for connectivity, guaranteed messaging, caching and security. Mobile Workflow relies on messaging between the server and a container on a device that invokes online operations to the back end or cached MBO data in the SUP server. Workflow Components In the workflow architecture shown in Figure 7, changes to back-end workflows, generally sent via Data Change Notifications (DCN), result in the creation of messages that are sent to the messaging server for dispatch. Spooled messages that meet a specified set of matching criteria are placed in a queue for processing by plug-ins to the messaging transformer component, which augment the message with application-specific data or processing instructions. 7

10 Messaging Service SUP Data Service Message Processor Mobile Device Message Interceptor DCN Servlet EIS Device Inbox Device Messaging Transformer Transformer Queue JMS Host DCN Servlet MMS DB Response Processor Application(s) Responder Response Queue DS Consolidated Database Figure 7. Workflow Architecture Once transformed, the augmented message may be queued for transmission to the mobile device when the device next connects to the SUP server, or the message may be sent to the device directly. These messages are stored in the device s inbox where they await the user s actions. When a user loads an in-box message, the appropriate form is loaded by the workflow application, and the user may perform application-provided actions (such as approving an expense request). The device user s responses are sent back to the messaging server. Depending on the application, the response action may be queued or may result in a synchronous action; this behavior is different from outbound message transformations, which are always queued. Regardless of whether the response action is queued or performed immediately, the application communicates with the SUP server to perform the action s unit of work. Mobile Synchronization Applications Synchronization applications provide transactional consistency between the mobile device, the middleware and the back-end system. These custom applications are designed and built to suit specific business scenarios from the ground up or could start with a bespoke application and adapt with a large degree of customization. Several application requirements must be considered to determine the best set of SUP technologies to employ with the associated sizing. Application designs that fail to take these criteria into account may have challenges in meeting their key performance indicators (KPIs). Cache Synchronization Cache synchronization allows mapping mobile data and service objects to SAP Remote Function Calls (RFCs) using Java Connector (JCO) and to other non-sap data sources such as databases and Web services. When SUP is used in a stand-alone manner for data synchronization (without DOE), it utilizes an efficient bulk transfer and data insertion technology between the middleware cache and the device database known as replication-based synchronization (RBS). In an SUP stand-alone deployment, the mobile application is designed such that the developer specifies how to load data from the back- end into the cache and then filters and downloads cache data using device-supplied parameters. The mobile content model and the mapping to the back-end are directly integrated. 8

11 This style of coupling between device and back-end queries implies that the back-end must be able to respond to requests from the middleware based on user-supplied parameters and serve up mobile data appropriately. Normally, some mobile-specific adaptation is required within SAP Business Application Programming Interfaces (BAPI). Because of the direct nature of application parameter mapping and RBS protocol efficiencies, SUP cache synchronization deployment is ideal: With large payloads to devices (may be due to mostly disconnected scenarios) Where ad hoc data downloads might be expected For SAP or non-sap back-ends Large payloads, for example, can occur in task worker (service) applications that must access large product catalogs or where service occurs in remote locations and workers might synchronize once a day. While SUP RBS synchronization does benefit from middleware caching, the direct coupling requires the back end to support an adaptation where mobile user data can be determined. Cache Synchronization Components The goal of synchronization is to keep views (i.e. the state) of data consistent among multiple tiers. The assumption is that if data changes on one tier (e.g. the enterprise system of record), all other tiers interested in that data (mobile devices, intermediate staging areas/caches and so on) will eventually be synchronized to have the same data/state on that system. Core Components The SUP server synchronizes data between the device and the back-end by maintaining records of device synchronization activity in its consolidated database along with any cached data that may have been retrieved from the back-end or pushed from the device. The SUP server employs several components in the synchronization chain (see Figure 8). Mobile Channel Interfaces provide a conduit for transporting data to and from remote devices. Two main channel interfaces provide messaging and replication. The Messaging Channel serves as the abstraction to all device-side notifications (BES, APNS and others) so that when changes to back-end data occur, devices can be notified of changes relevant for their application and configuration. This channel is also used to enable data synchronization on ios. 2 The Replication Channel serves as the conduit over which data is replicated between device and the mobile middleware. This is an efficient database row replication technology. Mobile Middleware Services (MMS) arbitrate and manage communications between device requests from the mobile channel interfaces in the form that is suitable for transformation to a common MBO service request and a canonical form of enterprise data supplied by the Data Services (DS). DS is the conduit to enterprise data and operations within the firewall or hosted in the cloud. The DS services and the MMS together manage the Consolidated Database (CDB) where data is cached as it is synchronized with client devices. Once a mobile application model is designed, it can be deployed to the SUP server where it operates as part of a specialized container-managed package interfacing with the MMS and DS components. Cache data and messages are persisted in the databases in the data tier. Changes made on the device are passed to the MMS component and replayed against the DS interfaces with the back-end. Data that changes on the back- end as a result of device changes, or those originating elsewhere, are replicated to the device database. 2 In a future release, cache synchronization will use the replication channel for ios as is currently done with all other devices. 9

12 Public Network DMZ Private Network Unwired Server (Clustered) Messaging Channel Mobile Devices Application(s) MBS Client UltraLite Outbound Queue Inbound Queue Replication Channel JMS Host Mobile Middleware Services Data Services Jaas Connection Pools LDAP Server RBS Client UltraLite Relay Servers MobiLink Unified Agent Service Sybase Control Center Data Change Notification SUP Data Tier (Active/Passive HA) Consolidated Database Cluster DB Unwired Workspace Enterprise Information Systems SAP Applications Databases SOAP/ REST Services User Agent DB Advantage Messaging DB Figure 8. SUP Cache Synchronization Architecture The Cache As the name implies this form of synchronization uses the cache as a mirror of what users see on the device. While the cache is not the system of record, it serves as an intermediary to allow the server to compare the last time cache elements were updated with the time the specific data elements on the device were last successfully synchronized. This mechanism allows the server to download only the elements that have changed since the last time that device synchronized. The cache is manifested in the CDB, which is a relational database management system. The server, or more specifically the application package hosted in the application server, communicates to the CDB through JDBC connection pools, which can be configured in the administration console. The MBO parameters and the relationship among MBOs define the shape of the cache tables. The internal implementation of these tables and the associated queries are not public and may change from release to release. Each package has its own cache, and the lifecycle of the cache is the same as the package. If the package is removed from the server, the cache is removed. Cache data can be shared or partitioned based on application parameters defined in the MBO model. If an MBO definition loads data where two application users have overlapping synchronization parameters, they are sharing the same data. On the other hand if the application model defines the MBO load parameters in a way that makes the data unique to a user (for example an employee ID), then the cache is partitioned and not shared. 10

13 Normally, shared cache data is reference or master data that is not typically updated by device users. Updating shared data will incur locking costs in the server and should be, if possible, accomplished infrequently and during periods of low user activity. The validity of cached data, like reference data, can be made invalid by configuring a cache group. By default, all MBOs belong to the same cache group. Available refresh settings for a cache group include: On (device) demand with a specified window of cache coherency Scheduled to refresh periodically after initial load Scheduled once for use where the initial load is done with a load query Always valid because the cache group will be updated by DCN Once the device demand or cache schedule triggers a load, all elements in the cache group are refreshed. To the extent possible, the MBO model should be designed in a way that partitions user data (with a unique user-specific key) that is meant to be updated from the device. The cache can be updated by a device user with the proper security role or by a DCN. When a device updates the cache, the changes from a result set can be optionally written to the cache along with the update to the back-end (apply results to the cache) 3. Alternatively, a portion of the cache can be invalidated, whereupon it will be refreshed. The latter method must not be used when a DCN is used to populate the cache since the server needs an operation to update the cache when it is invalidated. The DCN is a HTTP/JSON intranet-facing interface exposed through the built-in Web server for each package and the associated MBOs, with the intent that the back-end may proactively send changes to update the cache. Properly authenticated DCNs may send complete payload changes or notifications that something has changed (causing the cache to be invalidated for that record). Synchronization with Data Orchestration Engine The Sybase Unwired Platform Data Orchestration Engine (SUP DOE) deployment option provides additional flexibility in terms of allowing the system designer to model and consolidate SAP mobile content in the middle tier and separately layer distribution rules over this content. This approach is especially useful where back-ends cannot provide a mobile interface that serves up mobile data or where additional flexibility is required. Using this approach, the distribution rules can evolve separately from the content model, and different distribution rule sets can be used with the same content model. The technology to enable this behavior is built directly into the SAP NetWeaver stack and is therefore best suited to SAP-only implementations or where third-party back-end integration is already provided through NetWeaver. This method specifies BAPI CRUD interfaces to adapt back-end suite data sources to the middleware data consolidation area. The SUP DOE option was originally designed for mobilizing information workers who are mostly connected using applications such as CRM. As its name implies, this option consolidates all mobile back-end data and then, on a schedule, executes rules to determine mobile distribution. The SUP DOE option uses XML-based messaging between the DOE staging area and SUP where they are queued. The messages are then transformed into packets suitable for message-based synchronization (MBS) to the device a form that is far less effective in large transfers relative to its RBS cousin. 3 Restrictions apply to the mapping of back-end operations that are intended to update the cache so that the MBO attributes in the cache are properly maintained. During an update with this policy, the back-end data may not be properly reflected in the cache if the back-end further updates fields that have been applied during the cache write-through. This issue will be addressed in a future version of the server. 11

14 On some device platforms, MBS/DOE device downloads may be optimized for initial synchronization (when a user first connects) by transferring the entire binary representation of the mobile database. However, subsequent synchronizations will use MBS to insert change records into the device database one at a time. The user perceives MBS as delivering data over a period of time. If the application is mostly connected and payloads are reasonably sized, MBS performance may be appropriate for your application. In summary, the SUP DOE option is ideal where: The SAP back-end cannot support mobile queries The design dictates that the data distribution be accomplished in the middleware Mostly-connected device deployments are used Occasionally-connected device deployments are needed With small payloads With medium-sized payloads with overnight pre-processing An SAP-only solution is being built Data Orchestration Engine Components The SUP DOE architecture differs from its cache synchronization cousin in significant ways. Description of the content model and distribution rules are configured in the DOE tooling. Once the data model and rules are ready to be deployed, a package artifact known as Entity Set Definition for Mobile Applications (ESDMA) is used to communicate the application definition from within DOE. The ESDMA deployment tool creates the runtime artifacts in the Sybase server (see Figure 9). Figure 9. DOE Information Flow 12

15 The runtime artifacts in the Sybase server are limited to reliable delivery of messages both to and from devices. Data staging is done in the DOE middleware, while message store and forward bound for devices is done in the SUP messaging layers. A message-based server interconnect is used between the Sybase SUP server and its DOE component. Messaging, rather than database replication, is used to move data between back-end and device (see Figure 10). Public Network DMZ Private Network Unwired Server (Clustered) Messaging Channel Container Services Mobile Devices Application(s) MBS Client UltraLite Relay Servers Outbound Queue Unified Agent Service Sybase Control Center JMS Host Mobile Middleware Services Data Change Notification Data Services Jaas DOE-Connector http Messaging Connection Pools LDAP Server SUP Data Tier (Active/Passive HA) Consolidated Database Cluster DB User Agent DB Figure 10. SUP DOE Architecture Unwired Workspace SAP Applications NetWeaver Mobile (DOE) Advantage Messaging DB The DOE Connector (DOE-C) is the reliable bidirectional interconnect component between SUP and DOE. This interconnect transports XML payload, and the SUP messaging layers transform this payload into a form suitable for transmission to the devices. A reliable, encrypted, compression-capable, messaging infrastructure is utilized between the SUP server and the device. Once on the device client side, messages are stored within the MBS SDK persistence framework. Monitoring of SUP messages in the store and forward infrastructure is accomplished in the Sybase Control Center. Summary The Sybase Unwired Platform provides a range of integrated technology that allows developers to design and implement a variety of mobile applications quickly and deploy them into a secure environment where they can be administered from a single console. Depending on your needs, you can find more information through white papers covering subjects such as development fundamentals, security or detailed, device-specific developer guides. The SAP Developer Network also provides mobile discussion boards dedicated to SUP and associated literature that will further your understanding of the platform. 13

16 Sybase, Inc. Worldwide Headquarters One Sybase Drive Dublin, CA U.S.A sybase Copyright 2011 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, the Sybase logo, Afaria and MobiLink are trademarks of Sybase, Inc. or its subsidiaries. indicates registration in the United States of America. SAP, the SAP logo and NetWeaver are the trademarks or registered trademarks of SAP AG in Germany and in several other countries. All other trademarks are the property of their respective owners. 08/11