Article on International Journal of Mobile Communications "An Architectural Pattern Catalog For Mobile Web Information Systems"
An Architectural Pattern Catalog For Mobile Web Information Systems Walter A. Risi and Gustavo Rossi LIFIA. Universidad Nacional de La Plata, Argentina Calle 50 y 115, CC 11 [walter,gustavo]@lifia.info.unlp.edu.arAbstract.Mobile web information systems are becoming a common trend in most commercialand corporate environments. While the most visible problems in mobile systems arethe communication infrastructure and technical constraints of portable devices, thereare also architectural issues that must be properly addressed at the conceptual level.This paper describes our work towards categorizing and analyzing conceptualarchitectures for mobile web information systems. We have defined a domain-specificarchitectural pattern catalog for this domain, and mined several patterns from existing,well-known systems. Our goals are twofold. We aim at building a catalog ofarchitectural solutions proven successful in industrial practice and at defining a high-level, common language to describe these solutions.KeywordsSoftware Architecture, Mobile Computing, Ubiquitous ComputingBiographical NotesDr Gustavo Rossi is the director of LIFIA and Walter A. Risi is a researcher and industryconsultant the the same institution. LIFIA is a research laboratory of the NationalUniversity of La Plata, in Argentina.
1 IntroductionAs mobile web information systems (MWIS) become a common trend in mostcommercial and corporate information systems endeavors, new software engineeringchallenges arise. While the most visible problems in MWIS construction are thecommunication infrastructure and technical constraints of portable devices (e.g.mobile phones and PDAs), there are also architectural issues that must be properlyaddressed at the conceptual level.Current research in software artifacts regarding mobility concentrates primarily onfine-grained technological issues, such as wireless networking  and constrainedhardware . Unfortunately MWIS are seldom stable (because of technologicalimprovements or changes in the underlying business model and must be continuouslyupgraded or improved. Though it is widely known the importance of emphasizingdesign issues in applications that evolve fast, little attention has being paid toanalyzing the conceptual architecture issues that must be addressed when building aMWIS. Only recently some design problems related with mobile software have beenaddressed in the literature .Despite the technological hype, we claim that design of a MWIS architecture haschallenges that simply go beyond the purely technological restrictions. For example, aMWIS may require customizing its service for different types of users (mobile or not).On the other hand, a mobile information system may need to give mobile service tovery different type of mobile users (e.g. wired and wireless).To cope with this need, we have defined a domain-specific architectural patterncatalog for this domain, and mined several patterns from existing, well-knownindustrial systems. Our approach does not concentrate on the technical issues, butrather on identifying those architectures that better fit an application’s goals regarding
mobility. This catalog should be the basis of a high-level, common design language todescribe mobile architectural solutions. This language can be used during the processof architectural modeling of this kind of applications, in order to face problems at ahigher abstraction level by reusing successful solutions.This paper is organized as follows. In Sect. 2, we briefly review some of the conceptsunderlying this paper - such as software architecture and patterns. In Sect. 3, wepresent a preliminary classification of our patterns. In Sect. 4, we present some of thepatterns we mined. Sect. 5 presents shows how our approach relates to the actualprocess of building and analyzing MWIS. Finally, in Sect. 6 we draw some conclusionsand describe our lines for future work.2 Software Architecture and PatternsIn recent years, there has been some discussion regarding the software architecturedefinition. In this paper, we use the term software architecture to refer to a structuralplan that describes the elements of the system, how they interact together, and howthese interactions fit the application’s goals. In other words, we adopt the softwareblueprint view of architecture [12, 9]. We believe this is the most suitable view fortoday’s industrial practice.Though there are differences among the existing approaches to architecture, most ofthem agree in separating architectural concerns into several views . This paperconcentrates on what has been called the conceptual view . This view describes thearchitecture in terms of the high-level computational elements that comprise thesolution. In this view, the architect organizes the domain-specific computationalelements (components) and the interactions between them (connectors), building asolution that meets the application’s requirements. For example, an architectdesigning a compiler may produce an architecture consisting of several components
(e.g. parser, lexer), connected to each other by specific connectors (e.g. directprocedure calls).The concept of architectural patterns emerged several years ago  and it is indeedsimilar to the widely spread notion of design patterns . They share the intent ofcapturing, recording and conveying design experience. A pattern allows describing arecurrent design problem, together with its solution in an abstract way, such that thesolution can be applied to different (though similar) problems. They provide a designvocabulary for the domain to which they are applied. However, while design patternsare used at the so-called micro-architectural level in which the design components areclasses, objects and the interaction mechanisms are messages, architectural patternsdeal with a higher-level view of the system in which primitives are components andconnectors.3 Pattern ClassificationMobile devices are highly constrained in nature. Distinct devices have very differenttypes of limitations, and where one device is strong another may be very weak.However, a MWIS may have to consider the availability of the service to those verydifferent devices. On the other hand, mobile users are not necessarily interested inexactly the same kind of information that standard users are. The classification wedescribe in the following was defined to reflect the different arquitectural concernsrelated with these problems in the light of the already mined patterns – that is,following a bottom-up approach. It is clear that, as this area is evolving quickly, someconcerns will tend to be of less importance (for example, web access will be alwaysgranted) while others will have to be emphasized. Some concerns might have to befurther refined: for example as more customization styles and patterns arise it mightnot make sense to have such a coarse grained classification. Therefore, this
classification does not intend to be definitive but rather it must be seen as a set oforganizational axis, to reflect on the nature of the architectural problems involved.Web Accessing. This category addresses the issues about how to physically access theMWIS from a mobile client, depending on the constraints imposed by requirements anddevice restrictions. Hardware limitations have a strong impact on the way mobiledevices access to information. For example, a mobile phone has better accessingfacilities than a standalone PDA (i.e. without a modem) depending on synchronizationto a desktop machine to retrieve information. A PDA with a dial-up modem has betteraccessing facilities than a standalone PDA, but less autonomy than a wireless-enabledPDA. However, a dial-up connection is likely to be available in almost every city of theworld, while today’s wireless network areas are reduced. While some alternatives maybe preferable to others in certain contexts, the designer of the MWIS architecture mayhave to provide a solution that works both for high-end autonomous clients and alsofor a client very limited in terms of information accessing. A common reason for this isthat most adequate devices are also the most expensive ones, and the majority ofusers have devices that stand in the middle-ground, or even in the low-end of thespectrum.Web Navigation. This category addresses the issues that arise when a mobile client hasto navigate the web in a MWIS context. While a desktop client has a context suitable forfreely navigating the whole web, the choice of a mobile client is generally morereduced. A mobile client may be capable of processing only a subset of the whole web.Even if capable, the mobile user may only be interested in navigating through subset ofit – i.e. the subset that is relevant to her mobile context. Note that this category doesnot intend to address navigation from a hypermedia design perspective, but ratheraddress the concerns regarding the architecture supporting navigation.
For example, most PDA devices have specialized browsers to access web content.However, most of these browsers do not work well with any page, but only with asubset that are encoded in such a way that they are suitable for mobile devices – e.g.smaller screens and a limited HTML syntax. A mobile user may not want to navigatethe whole web in his device, but rather the subset that is suitable for its device and itsneeds – e.g. a set of mobile channels, suitable for PDA accessing. Consider also that adesktop user may feel comfortable by typing a URL or launching a web search facilityto find some information, but an urged mobile user may not find that appropriate inher context – and rather would prefer a more straightforward way to select the weblocation in which she is interested.Constrained devices are weaker and more specialized than mainstream devices. Thechoice of available web locations through which the mobile user can navigate isgenerally a subset of the whole universe of choices, not only because of hardwarelimitations but also because of the specialized interests of the mobile user. A mobileclient in these conditions should not have to deal with the complexity of addressingthe whole web, but rather the subset in which it is interested.Customization. This category provides architectural patterns that address the problemsof customizing the MWIS themselves. Again, the constrained nature of mobile devicesposes physical and conceptual restrictions to the information that can be browsed insuch a device. A mobile device may not be capable of interpreting every web siteencoding. Even if so, the mobile device user may not be interested in the same view ofthe information that a desktop client is.For example, while most PDA devices have web-browsers, the screen limitations makesome web pages impossible to be viewed on such devices. Some browsers even do notsupport the complete HTML syntax, and therefore cannot access arbitrary pages on the
web. Finally, a mobile user accessing a web site may be interested only in informationrelevant to its mobile context - e.g. a businessman accessing a financial company website is more interested in finding market information rather than the history of thecompany.A mobile user may be interested in the same web location that a non-user user isinterested in, but not exactly in the same view of that information. Mobile devices maynot be powerful enough to process the web site – e.g. for limitations in parsing theinformation format. Even if so, mobile users are interested in a view of the informationsource that is relevant to their mobile context.4 Pattern CatalogIn this section we present some of the patterns we have mined in the categoriesmentioned in the previous section. We use a format similar to the one used in ,though slightly customized to better fit the higher-level nature of architecturalpatterns.Our pattern format includes an UML  diagram to explain the structure of thesolution. Among the several approaches to the usage of the UML for softwarearchitectures,. we have deliberately chosen the one defined in  for being both simpleand expressive. Note that we have actually simplified the mentioned notation forsimplicity reasons, and instead we compliment our diagrams with textual explanations.The diagram depicted in Fig. 1 shows an example of the notation we adopted. Thediagram shows a component connected to a connector. A component is anarchitectural entity that represents a conceptual unit of computation. The componentexposes its functionality through one or more ports (small black squares). Thecomponent can interact with other components through connectors, which represent acommunication mechanism. A connector connects two or more components, through
their ports. Finally, both components and connectors can be nested. These elementsare actually stereotyped classes - for more information about the usage of thesestereotypes in this context, refer to .It is important to note that a conceptual architecture’s components and connectors donot necessarily map exactly to an implementation’s components and connectors.Rather, the conceptual entities show those functionality blocks (components) and theirrelationships (connectors) that must be present to provide a certain functionality, butthe implementation may imply that several entities are mapped into a singleimplementation block, or vice-versa.4.1 Web Accessing Pattern: Static AccessingIntent. Provide a mobile client with the possibility of accessing a MWIS, when the clientitself is not capable of accessing the web on its own.Problem. You have to access an MWIS from a constrained device that does not haveenough capabilities to access the web on its own (e.g. a PDA without a modem andwithout wireless capabilities). It may happen that the most common configuration ofsuch a device does not provide such facilities (e.g. most Palm and PocketPC devices donot provide a modem in its basic configuration). It may also be the case that thetargeted line of devices does not have such facilities at all.Solution. Allow the mobile client to access web content through non-mobile accessingchannel, aided by a static device capable of accessing the web. See Fig. 2.Rationale. The Synchronization connector is in a non-mobile connection mechanismthat gives the mobile client a (possibly partial) ilussion of a connection to the web.Inside the Synchronization connector resides a Request Handler that mediates betweenthe Mobile Client and the Web Interface. The Update Decission Engine decides if the
information in the Mobile Client is updated with respect to the actual MWIS beingaccessed, and if not, retrieves it.Whenever the Mobile Client requires accessing the web, the Synchronization connectorreceives the request, routes it through the Update Manager which decides whichinformation to gather from the web, and finally physically accesses the web throughthe Web Connection.Consequences. Any portable device gets the possibility of interacting with a MWIS aslong as a suitable synchronization connector is built. The autonomy of the client isreduced, since the web accessing process requires the presence of the synchronizationmechanism. Having to provide a suitable synchronization connector may involveadditional work for the developers.Known Uses. The AvantGo  service uses Palm OS’s HotSync  technology totransfer information from particular web locations (AvantGo channels) to the mobileclients (Palm OS or PocketPC handhelds) through synchronization with a desktopmachine. AcroClip  for Casio OS handhelds also uses this pattern.4.2 Web Navigation Pattern: Web Channel BrokerIntent. Simplify a mobile client’s web addressing capabilities. Have the web addressspace preprocessed by an intermediary.Problem. You have to allow the mobile user to retrieve information from an arbitrary orpredefined set of web sites (e.g. several MWIS). You want to keep the mobile clientsimple (e.g. due to hardware restrictions), and therefore you need to simplify the wayto address whole web. It may also be the case that you want to prevent mobile clientsto access arbitrary web locations – e.g. for corporate security reasons. In that case, youneed an intermediary capable of assuming the responsibility of addressing the whole
web and presenting a transformed universe to the mobile client – e.g. a set ofcorporate locations.Solution. Provide a broker capable of interacting with the whole web, presenting themobile client with a transformed (possibly reduced) view of that universe in terms ofweb channels, where that channel is a web location suitable for the user’s mobilecontext. See Fig. 3. Rationale. The Mobile Client connects to a Web Channel Brokerthrough a Web Connection. Instead of accessing the web directly, its requests arerouted through the Web Channel Broker. The broker queries an internal database tofind out to which actual MWIS to connect, and finally routes the request to the actualsite through a Web Interface component.Consequences. The mobile client addressing system may be simplified, but having toprovide a suitable broker may involve additional work for the developers. The brokerprovider has control on the web subset that the mobile clients access.Known Uses. AvantGo  centralizes the access to a growing set of channels, whereAvantGo’s M-Commerce server acts as a broker between the MWIS and the actualmobile clients. The AcroClip  service also offers access through channels, controlledby a proprietary broker.4.3 Customization Pattern: External CustomizerIntent. Provide a mechanism for adapting web content to mobile clients which isindependent of the MWIS of interest.Problem. You have to deploy information from arbitrary MWIS in a constrained devicethat does not support the format in which those sources encode their information (e.g.Palm’s m100 handheld, for which a full-blown web browser is not available). Thepossibility of making customized versions of the MWIS is unfeasible (e.g. because thenumber of MWIS of interest is too big, because the number of different targeted
devices is large, or just because the web masters are not interested in providingcustomized versions).Solution. Create a component able to convert data from arbitrary MWIS to a formatsuitable for the potential clients. This component is external to the MWIS of interest.See Fig. 4.Rationale. The Transcoder is a component able to convert between the encoding andformat of standard web sites, and those required for a set of mobile devices. TheMobile Client connects to the Transcoder through a Web Connection. The transcoderpasses requests through a converter from mobile requests to web requests, andforwards them to the actual MWIS through a Web Interface. The same happens in theopposite direction, and answers from the MWIS are passed through a converter of webto mobile format before they reach the mobile client.Consequences. The MWIS provider has no additional work in the customization of theinformation for the mobile clients. The transcoder automatically handles this task.Building the transcoder can be a difficult task. There maybe several mobile clients inmind, with significant differences that the transcoder must support. The parsing of theoriginal information source can be difficult in itself; being external and unaware to theMWIS internal design, the transcoder may have to cope with a wide variety of possibletranslations.Known Uses. PumaTech  provides a service that allows accessing to standard webpages via Palm OS devices. PumaTech’s solution relies on conversion heuristics thatconvert pages to version suitable for constrained hardware, in a way that semantics arepreserved. IBM also provides a transcoder-based solution as part of its Webspherefamily of products . AcroClip  has built-it transcoders for several web sites, andalso allows users to define their own.
4.4 Customization Pattern: Internal CustomizerIntent. Provide the mobile client with an application response directly suitable for itsmanipulation, so that no external customization is required.Problem. In many situations you need to adapt an application’s functionality dependingon the client’s device (a desktop browser, a PDA browser, a mobile phone) either in adynamic way or fixed way. You may need not only to adapt the encoding of theinformation to one suitable for the client device, but maybe also the applicationresponse and behaviour may vary – for example you have just signed an agreementwith a cellular phone company and you want to induce customers to use that device.Since the customization rules are highly tied to the nature of the MWIS, providing anexternal customizer that can handle all this rules is almost impossible or at least tooexpensive.Solution. Move the customization mechanisms into the design of the MWIS itself,allowing it to provide different responses depending on the client – whether differentresponses may imply different encoding and different behaviour. See Fig. 5.Rationale. The Mobile Client connects to the MWIS through a Web Connection. TheMWIS queries several sources of personalization information - Rule Engine, UserProfiles – to generate the appropiate query to the actual application model. Theapplication’s model answer to the personalized query is then returned as the responseof the request.Consequences. The MWIS is specially designed for the mobile clients in mind, so thereare less possibilities that it does not suit perfectly its clients. The content provider hasadditional work, since it has design application specific customization mechanisms tohandle the potential clients.
Known Uses. In the UWA (Ubiquitous Web Applications) reference model , rules areseparated from the application and the context model is itself composed of user,device and network sub-models. In the Munich Reference Architecture for adaptivehypermedia applications  a similar approach is used. WebML  also uses a variantof this pattern.Related Patterns. The External Customizer pattern is similar to the Internal Customizerpattern in that it provides an automated way of presenting different views of theinformation to the mobile clients. However, while the External Customizer focusesmainly on the looks of the information, the Internal Customization pattern focuses onthe guts of the information generation process. Therefore the External Customizer actslike a facade over a system, being an information-unaware solution. In the InternalCustomizer pattern, the rules and context which comprise the customizationmechanism are aware of the kind of information the system provides.4.5 Customization Pattern: Custom AuthoringIntent. Design and build an MWIS version customized to the mobile client, so that noexpensive customization mechanism is required.Problem. You have to deploy information from information sources (e.g. web sites) in aconstrained device that does not support the format in which those sources encodetheir information (e.g. Palm’s m100 hand-held, for which a full-blown web browser isnot available). You don’t have the resources or expertise to build or buy an automatedcustomization mechanism.Solution. For each information source of interest, provide a customized version of thatsource, so that the format is exactly the one suitable for the client. See Fig. 6.
Participants. The Mobile Client retrieves information directly from the MWIS, throughthe Web Connection. Since the MWIS is already customized for the Mobile Client, noadditional processing is necessary.Consequences. The information is specially designed for the mobile clients in mind, sothere is no possibility that it does not suit perfectly its clients. The content providerhas additional work, since it has to provide a customized version of its informationsources for each of the mobile clients in mind. Updating the information can be aheavy task, if there are several customized versions to be maintained.Known Uses. AvantGo’s authoring guidelines  encourage content providers todeliver their MWIS specially authored to cope with mobile devices’ limitations.5 From Patterns to ApplicationsIn this section we show how the patterns we presented can help in both describing acommercial solution and defining a solution to fit a business goal. We present twoexamples on the usage of patterns that go from representing commercial architecturesto potential usages of these patterns in an enterprise context.5.1 Representing AvantGo’s Dynamic Mobility ModelThe Dynamic Mobility Model (DMM)  is the solution suggested by AvantGo to providemobile access to web-based information systems. In Fig. 7 we show the conceptualarchitecture of the DMM. The Static Accessing pattern is used to allow non-wirelessdevices to access the system (AvantGo uses AvantGo Connect and Palm OS HotSync asits Synchronization mechanism). A Web Channel Broker (AvantGo’s M-CommerceServer) provides the mobile clients with a reduced version of the internet, based onchannels. Finally, AvantGo suggests their content providers to provide informationencoding in a format directly suitable for mobile clients, thererfore encouraging aCustom Authoring solution (although an Internal or External Customization solutions
are also feasible, as long as AvantGo can ignore their internal workings). Having aconceptual description of a technological infrastructure such as AvantGo enablesarchitects to analyze the solution in a completely objective way. Given an actualproblem, the architect can define the best-fit architecture and then compare it toAvantGo’s to see if it really fits the application’s goals.Actually, AvantGo also lets wireless clients access their broker through awireless connection. However, we limited here to show the static part sincethat is the one that best illustrates the usage of the patterns.5.2 Customized Mobile Access to a Corporate DatabaseA software company wants to provide access to its corporate database to both theirvendor force and also its customers. For its vendor force, it wants to provide updatedinformation about their products, solutions and prices. Instead, for their customers, itwants to provide information about special offers and customized support. The firstproblem the architect faces is providing a customized view of its information databasefor the different users that may be interested in that information.Since the vendor force needs updated information, the company decides to provide itsvendors with wireless-enabled, high-end PDA devices. However, the customers have avariety of mobile devices, most of them not-wireless enabled. Thus, the secondproblem the architect faces is providing both wired and wireless access to theinformation. Also, the information encoding may be different for the high-end vendordevices, compared to the possibly-low-end customer devices. The architect browsesthe architectural pattern catalog and selects those patterns that can help in solving theproblem at hand. The resulting conceptual architecture is depicted in Fig. 8. Theproposed architecture is a high-level view of the solution. The Static Accessing patternis used to provide wired access to the MWIS. The Internal Customization pattern is
used to provide different views on the same information source - the corporatedatabase. Once the architecture is depicted, the architect can then discuss aboutbuilding or buying a solution, depending on the available schedule and expense.6 Conclusions and Future WorkThe current work on MWIS architectures is mainly focused on the technological aspectof this kind of systems. While there is considerable research in approaches forimplementing systems using a certain wireless technique or other, there are no studiesabout how the mobility aspect conceptually relates to a MWIS. This paper presented anapproach to describing, categorizing and analyzing conceptual architectures for mobileaccess to web information systems.Our approach is based on the architectural pattern concept. We presented severalpatterns that represent common mobility configurations existing in current industrialpractice.Abstracting existing configuration as architectural patterns provides the designer witha catalog of architectures. The practitioner can then choose the architectural structuresthat best fit the business goals, without having to rely on vendor-specific solutions orterminology.We are currently working on mining other architectural solutions that occur in existingMWIS. Our intention is to grow a complete and solid architectural pattern language forproviding mobile access web information systems. We are also working on defining anarchitectural methodology for the better usage of these patterns. Our main intention isto integrate these patterns into existing modeling tools and/or languages, in order toprovide the architect with a toolbox of primitives so he can describe his mobileapplications in a higher-level of abstraction.
References AcroClip. http://www.pcsync.de. AvantGo M-Commerce Server. http://www.avantgo.com. HotSync Technology. http://www.palm.com. PumaTech BrowseIt Server. http://www.pumatech.com. Transcoding Publisher. http://www.websphere.ibm.com. WebML. http://www.webml.org. R. J. Erich Gamma, Richard Helm and J. Vlissides. Design Pat-terns,Elements ofReusable Object-Oriented Software. Addison Wes-ley Professional Computing Series,1994. O. M. Group. UML (version 1.3). OMG, June 1999. C. Hofmeister, R. Nord, and D. Soni. Applied Software Architecture. Addison Wesley,2000. G. Kappel, W. Retschitzegger, and W. Schwinger. Modeling Ubiquitous WebApplications: The WUML Approach. In Interna-tional Workshop on Data Semantics inWeb Information Systems (DASWIS)-2001), co-located with 20th InternationalConference on Conceptual Modeling (ER2001), Proceedings, November 2001. N. Koch and M. Wirsing. The Munich Reference Model for Adaptive HypermediaApplications. To be presented at the 2nd International Conference on AdaptiveHypermedia and Adaptive Web Based Sys-tems, 2002. P. B. Kruchten. The 4 + 1 View Model of Architecture. IEEE Software, 12(6):42–50,Nov. 1995. J. Noble, C. Weir, and D. Bibby. Small Memory Software: Patterns for Systems withLimited Memory. Addison-Wesley, 2000.
 S. Schaefer, S. Marney, T. Willis, and K. Parkkinen. OOPSLA Work-shop onArchitectural Patterns for Wireless Computing. 2001. M. Shaw. Patterns for Software Architectures. In J. Coplien and D. Schmidt, editors,Pattern Languages of Program Design, chapter 24, pages 453–462. Addison-Wesley,1995. Component A Notation Component A.1 Connector C Connector A.C.1 Component B Component A.2 Connector D Connector D.1 Component D.O.1 Connector D.2 Component E Fig 1. Using the UML to Express Software Architectures
SynchronizationStatic Accessing Mobile Connection Request Handler Update Manager DetermineUpdate Web Connection Mobile Client MWIS Fig 2. Static Accessing. Mobile Client WebConnection Web Channel Broker Web Channel Broker QueryDatabase Request Handler Forward MWIS Database Web Interface MWIS WebConnection Fig. 3. Web Channel Broker
Mobile Client WebConnection External Customization Transcoder Request Handler Forward ConvertToMobile ConvertToWeb Web Interface ToMobileFormatConverter ToWebFormatConverter MWIS WebConnection Fig. 4. External Customization Mobile Client Web Connection Internal CustomizationMWIS UserProfileDatabase QueryProfile Request Handler RuleDatabase QueryRules Context QueryContext Application Model QueryModel Fig. 5. Internal Customization
Custom Authoring Mobile Client WebConnection Customized MWIS Fig. 6. Custom Authoring Wireless Connection :: AvantGo Client :: HotSync + AvantGo Connect :: Web Connection Mobile Client Static Accessing AvantGo M-Business Web Server :: HTTP :: Server :: Customized MWIS Web Connection Web Channel Broker Fig. 7. AvantGo’s Dynamic Mobility Model Vendor Client :: Customer Client :: Mobile Client Mobile Client Wireless Connection :: Wireless Connection :: HotSync :: Web Connection Web Connection Static AccessingMWIS Corporate User Base :: QueryProfile Request Handler UserProfileDatabase Usage Rules:: QueryRules RuleDatabase User Context :: QueryContext Context Corporate Database :: QueryModel Application Model
Fig. 8. Architecting Customized Mobile Access to a Corporate Database