Symbian OS Communications (779884), страница 76
Текст из файла (страница 76)
The Replace allows theDM server to change the unique name of an unnamed node – this willbe performed by the DM framework and does not require interactionwith the DM adapter.• Default Value =• Description =./CommsBook2ndEd/<x>*/DomainName• Scope = dynamic• Occurrence = one• DFFormat = chr. This node is a leaf node that has a text value.• DFType: MIME = text/plain. This node supports the text/plain MIMEtype.• AccessType = Get, Add, Replace.
Add is supported to allow a newunnamed node and all child nodes to be added in a single transaction.• Default Value =• Description =./CommsBook2ndEd/<x>*/UserName• Scope = dynamic• Occurrence = one• DFFormat = chr• DFType: MIME = text/plain• AccessType = Get, Add, Replace• Default Value =• Description =./CommsBook2ndEd/<x>*/Password• Scope = dynamic• Occurrence = one• DFFormat = chr• DFType: MIME = text/plain• AccessType = Add, Replace. Only Add and Replace are supported asthe reading back of the password is seen as a security risk.376OMA DEVICE MANAGEMENT• Default Value =• Description =./CommsBook2ndEd/<x>*/ResourceName• Scope = dynamic• Occurrence = one• DFFormat = chr• DFType: MIME = text/plain• AccessType = Get, Add, Replace• Default Value =• Description =./CommsBook2ndEd/<x>*/Language• Scope = dynamic• Occurrence = one• DFFormat = chr• DFType: MIME = text/plain• AccessType = Get, Add, Replace• Default Value =• Description =.
/CommsBook2ndEd/<x>*/ConRef• Scope = dynamic• Occurrence = one• DFFormat = chr• DFType: MIME = text/plain• AccessType = Get, Add, Replace• Default Value =• Description =./CommsBook2ndEd/<x>*/UseTLS• Scope = dynamicTHE EXAMPLE DM ADAPTER377• Occurrence = one• DFFormat = bool.
This leaf node has a Boolean value.• DFType: MIME = text/plain. This is text/plain as the leaf node expectsa text representation for the Boolean values.• AccessType = Get, Add, Replace• Default Value = FALSE. If this leaf node is not explicitly added thenthe default value will be false.• Description = If ‘TRUE’ then a TLS connection is used. Expectedvalues TRUE or FALSE.This MO information can be published to allow operators of DMservers to determine how to setup and change the accounts for theexample XMPP application from this book.The next task is to identify the operations we need to perform usingthe DM adapter.Operations to perform on interior nodes:• Adding an unnamed node – when an Add command is received onthe unnamed node, this signifies that a new account is to be added andthat the account is associated with the unique node name containedin the URI.• Deleting an unnamed node – when a Delete command is receivedon an unnamed node, the account associated with that unique nodename must be removed.• Get on the CommsBook2ndEd node – when a Get command isreceived on the CommsBook2ndEd node, the DM adapter must returna list of the unique node names for all of the accounts.
There are twoconsiderations here:–accounts are already in the management tree – methods are available from the DM framework for mapping the account IDs to theunique node names.–accounts that are not in the management tree – the DM adaptermust generate new unique node names for all accounts that have nomapping to the management tree.• Get on an unnamed node – when a Get command is received on anunnamed node, the DM adapter must return a list of all the childnodes of that node (i.e., the settings that exist for that account), whichexist on the device.Operations to perform on leaf nodes (for all of these nodes the accountto be accessed is specified by the unnamed node in the URI):378OMA DEVICE MANAGEMENT• Adding or replacing a ConRef leaf node – when an Add or Replacecommand is received for the ConRef leaf node, the DM adapter mustconvert the value, given as URI in the management tree, to a tableentry in the CommsDat database.
The table entry value is then storedin the account data. If the keyword INTERNET is given as the URI,then the account data is stored as zero.• Adding or replacing a UseTLS leaf node – when an Add or Replacecommand is received for the UseTLS leaf node, the DM adaptermust convert the text/plain representation of the Boolean value to thecorrect logical value and store this value in the account data.• Adding or replacing all other leaf nodes – when an Add or Replacecommand is received for a leaf node, the associated settings data mustbe changed to the given value.• Get on the ConRef leaf node – when a Get command is received forthe ConRef leaf node, the DM adapter must convert the CommsDattable entry from the value stored in the account data into a URI in themanagement tree.
This URI will reference the access point that ownsthe settings for that CommsDat table. If the account data is zero, thenthe keyword INTERNET is returned to show that the default accesspoint is used.• Get on the UseTLS leaf node – when a Get command is received forthe UseTLS leaf node, the DM adapter must convert the logical valuefrom the account data to the text/plain representation.• Get on the Password leaf node – a Get command for the Passwordleaf node should never be received as the DDF specifies that the nodedoes not support the Get access type.• Get on all other leaf nodes – when a Get command is received for aleaf node, the DM adapter must return the value stored in the accountdata.Other design considerations:• Atomic commands – the DM adapter must be able to handle multiplecommands in a single atomic transaction as described in the OMA DMspecification.
Transactions can span multiple DM adapters and if anyof the commands fail then the entire transaction is rolled back. Thereare two parts to a transaction, the start and end of the transaction.The start signifies that all following commands (prior to the endnotification) are within the transaction. The end of the transaction iseither the rolling back of the commands within the transaction or thecommittal of the transaction.THE EXAMPLE DM ADAPTER379–Rolling back atomics – when requested, the DM adapter shouldattempt to revert the changes made within the transaction. TheDM adapter must report the success or failure of the reversion foreach of the previously completed commands.–Committing atomics – when requested, the DM adapter must commit the changes that were made within the transaction to ensurethat they are persistent.• Handling commands on multiple accounts – when necessary the DMadapter must be able to handle commands on multiple accounts.
Thisis particularly relevant if multiple accounts are added, changed orboth are within a single atomic transaction.Let’s now take a look at the code that implements the DM adapterwe’ve just described. The first tasks to perform when implementing aDM adapter are to create the resource file that will register the DMadapter as an ECOM plug-in to the DM framework and the project MMPfile. To register it as an ECOM plug-in to the DM framework the DMadapter must have a resource file in which it declares the interface uid as0x102018B4. The DM adapter must also state within the MMP file thatthe TARGETTYPE is PLUGIN: this will create the appropriate binary foran ECOM plug-in.In order for the DM framework to be able to communicate with the DMadapters, each DM adapter must implement the specified ECOM interfacedetailed in<devman/SmlDmAdapter.h>.
This provides the interface theDM framework requires to access the DDF structure of the DM adapter,pass commands from DM servers and to notify the DM adapter of atomicoperations. The classes defined in this file are shown in Table 12.1.For the DM framework to be able to utilize the DM adapter, the DMadapter must derive from the CSmlDmAdapter class; this requires theDM adapter to implement methods to:• provide the DDF structure the DM adapter supports• provide a version number for the DDF information• update leaf nodes (these do not differentiate between Add and Replacecommands)• delete a node and its children• get leaf node data and the size of the data• get the children of an interior node• add an interior node• perform an Execution on a node380OMA DEVICE MANAGEMENT• copy node(s) to another location• handle atomic transactions• stream large data• complete any remaining commands.Table 12.1 Defined classesClass nameDescriptionMSmlDmAdapterAbstract interface containing the purevirtual methods for CSmlDmAdapter.Developers may find this useful for testing,but should not use it as a direct base fortheir own adaptersCSmlDmAdapterThe ECOM interface to be derived from byall DM adapter plug-insTSmlDmMappingInfoEncapsulation of a mapping between anode of the DM tree and some externalsettings storeMSmlDmCallbackServices provided by the DM framework toDM adapter plug-ins, including access tomapping data, access to other nodes of theDM tree, and callbacks for completion ofDM commandsMSmlDmDDFObjectRepresentation of single node in theadapter’s DDFTSmlDmAccessTypesThe set of DM commands that can bepermitted on a particular node in theadapter’s DDFTo be able to access methods that are provided by the DM framework foruse by DM adapters, the CSmlDmAdapter class provides a method Callback() that returns a reference to an object of type MSmlDmCallback.This object can then be used to call selected methods of the DM framework.All of the DM command interface methods provide the URI to identifythe node that the command is for, but this does not translate as easilyto C++.
To determine which node the command is for, it is necessary tosplit the URI on the ‘/’ separator. This will provide two useful pieces ofinformation: the depth or number of nodes in the URI and the name ofthe node the command is for.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
