• Cognizant 20-20 InsightsKey Performance Considerations WhenDesigning Mobile Applications Using SOAA service-oriented arc...
and location. The widespread reach coupled with        While these mechanisms are valid and help build               compa...
Principles of Performance                                 precious resources in the device and will be detri-             ...
Gateway Services                                                                      External Services                   ...
•	 End-point channel: Ability to do service invo-     •	 JSON parser.  cations with minimal programming efforts (and      ...
Sample Request Object for ‘Medical News’           {           “UserId”:“MobileUser1”,           “ApplicationName”:“Medica...
Runtime View           Device Request (Input from Mobile Devices): App Name, App Id, Template Name, etc                   ...
AcknowledgmentsThe authors express their profound gratitude to Cognizant’s Saikumar Jagannathan, Chief Architect,for his c...
Upcoming SlideShare
Loading in …5
×

Key Performance Considerations When Designing Mobile Applications Using SOA

2,054 views

Published on

Service-oriented architecture can dramatically help IT and others produce mobile applications to serve the life sciences industries and all others; we explore the role played by UI templates, service repsonse objects, loose coupling, and other app development tactics.

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,054
On SlideShare
0
From Embeds
0
Number of Embeds
144
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Key Performance Considerations When Designing Mobile Applications Using SOA

  1. 1. • Cognizant 20-20 InsightsKey Performance Considerations WhenDesigning Mobile Applications Using SOAA service-oriented architecture can enable IT to consistently create andimplement high-performance mobile apps that meet the just-in-timebusiness needs of professionals in life sciences, healthcare and beyond. Executive Summary information is disseminated. From print media to the Internet to mobile, ways of reaching Access to enterprise information is increasing- consumers are continuously evolving. The first ly through mobile channels. Existing informa- shift from print media to the Internet created tion assets are typically being exposed as Web all sorts of emotions — cynicism, optimism and services to enable rapid development of mobile guarded hope. That the Internet has permeated applications. Due to the unique nature of mobile every aspect of human existence is hyperbole devices, however, performance requirements no longer. Even in common experience, one can need to be taken into account. notice that newspapers, product brochures and This white paper discusses key principles that talk shows de facto end with a reference to a Web can help IT organizations create mobile apps that site for more detailed information. can overcome performance challenges. It details The force of change was so dramatic that those the association of a service response object with who failed to move or reluctantly embraced a UI template, configurable way of contracts change ended up as anachronisms and consigned maintenance, gateway services as single service to obscurity. invocation and loose coupling. An application built using these principles is discussed with One can see the same parallels experienced in the specific reference to how physicians’ needs for shift from the Internet to mobile devices. Where information access can be fulfilled in a timely earlier the onus was on the user to seek and fashion. The paper concludes with the possibili- locate the information on the Web using search ties of application of the suggested principles in engines, today’s models predetermine what users other circumstances. want and create readily consumable information capsules. The ascendancy of such new modes is As the Information World Turns fueled by the emergence of the mobile Internet. When Confucius said: “They must often change The mobile Internet has empowered on-the-go who would be constant in happiness or wisdom” users with access to the same level of informa- he must have been anticipating today’s world tion that is available to a more stationary home of real-time information ubiquity. Consider how Internet user, transcending the limitations of time cognizant 20-20 insights | october 2012
  2. 2. and location. The widespread reach coupled with While these mechanisms are valid and help build compactness of the mobile devices has made a more comprehensive understanding of medical them attractive and utilitarian. That these devices science developments, oftentimes physicians are usually always on helps ensure immediate dis- need to have immediate access to real-time infor- tribution of information. mation. Conceivably, such situations occur at the point of care where, as an example, the suitability In a pioneering work on mobile information of a particular drug for the visiting patient may access,1 the authors argue with great foresight need to be determined. that mobile phones will emerge as the preferred and primary platform for information access. On the other hand, pharmaceuticals companies The need to be extremely context-aware and realize that multichannel engagement with understand the intent of the user is predictive physicians is essential. They know that enabling to success in the mobile world. An interesting physicians to maximize patient interaction is the blog from Harvard Business key to success. Developments in medical science Pharmaceuticals Review 2 delineates the therefore must be converted to a stimulating companies are innovative, transforma- dialogue with patients. The mutual success of tional possibilities in health patient-physician interaction typically yields increasingly looking care leveraging mobility the best possible outcome for both parties.at creating a means to trends. Cognizant of this, pharmaceuticals companiesarm physicians with all From here, we will share are increasingly looking at creating a means to arm physicians with all necessary information,necessary information, some of our learning in available on demand, to help determine the most available on demand, architectural principles appropriate treatment options for the ultimate that we have successfully to help determine applied to realize high- benefit of the patient. the most appropriate performance mobile appli- Manhattan Research4 suggests that more than treatment options cations. We first talk about 72% of U.S. physicians have smart phones; of physicians and their infor- that, 80% agree that their devices are essential to for the ultimate mation needs and how the their practice. This finding is of crucial importance benefit of the patient. mobile channels are playing as it attests to the new means of working for a greater role; we then physicians. The adoption of mobile devices by the discuss the key architectural principles that can medical community for professional purposes is be applied for high performance, and walk through set to only expand with time. an implementation scenario. We conclude with a discussion of how the architectural principles can Recognizing the prevalence and increased market be applied in other situations as well. acceptance of mobile-based applications, in July 2011 the Federal Drug Administration (FDA) Physicians and the World of released a draft guideline5 on mobile medical Information: Changing Contours applications. The FDA recently approved Mobile MIM, an application that lets physician view for More than ever before, physicians face the diagnostic purposes CT, MRI and PET images. daunting task of staying informed about develop- Similar mobile application developments6 are ments in medicine. The rapid rate of the informa- emerging elsewhere, as well. tion explosion, coupled with an increasingly aware and assertive patient community demanding the With more and more physicians using mobile latest and the best, is further challenging them to devices, system architects face the challenge of stay abreast of new developments. making information available for effective use in these devices. The devices are constrained in real This information is diverse and it ranges from estate and have much lower processing power drug databases to side effects to dosage compared with desktop and laptop computers. guidelines to the latest news about the adverse The architectural principles must reflect the effects of a drug.3 The timeliness of information understanding of these natural limitations yet and the ability to access the same is of paramount not compromise on performance or usability. In importance. Traditional knowledge-gathering the next section we will focus on the architectural mechanisms such as literature review, informa- principles that are very effective for creating a tion from pharmaceuticals companies, subscrip- high-performing, accessible device that delivers a tions to information banks and discussions with wide array of information to mobile users. colleagues are tedious and time-consuming. cognizant 20-20 insights 2
  3. 3. Principles of Performance precious resources in the device and will be detri- mental to performance. Gateway services provideThe five principles described below are influenced a uniform way of constructing the service requestby the following well-established, primitive archi- irrespective of whatever the client is looking for;tectural considerations: be it for medical calculators or label informa-• Clear separation of concerns. tion, the originating request is always made to• Grouping of reusable components. the gateway services. The URI of the service is always the same and takes the following form:• Drive configuration at all levels. https://<site>/GatewayService.svc. The template• Establish contracts between layers and name will be appended to the service call and that anticipate changes. serves to indicate the kind of information in whichPrinciple 1: Predefine UI Templates and the client is interested.Associated Response Types Gateway service also handles another importantIt is possible to create predefined UI templates part of the job: All service invocations from thefor some of the most commonly sought after middle layer are handled by the gateway services.information. For instance, one can have a list-type This helps the client insulate itself from thedisplay while showing medical news; for media concern of whether the sources are inside orinformation, one can display a list of images. If outside the firewall. Figure 2 depicts the corethe responses from the enterprise information function of gateway services.systems are formatted in an appropriate way forpredefined methods of rendering (templates), Since the handling of all services is centralized tothe display in the client devices can be made gateway services, this helps in scalability as onefast. This also offers an elegant way to manage can provision necessary hardware depending onchanges. The idea of predefining the display and the load.contracting with a suitable response structure isat the heart of this architectural principle. Principle 3: Configurator — Configurable Contracts MaintenanceFigure 1 describes some of the UI templates and The “Configurator” is a bridging mechanismthe contracted response structures. between the variety of information sources and the client (device). There could be different typesPrinciple 2: Gateway Services – Single Service of information that a physician may be looking for,Invocation so the mode of presentation and the informationWhen the mobile client requests data, it will be sources will be different. Much like Web servicesideal if the client is not burdened with having to abstract the underlying information sources andknow the service name and make the necessary exposes these services in one uniform construct,request construction. Such an act will consume the Configurator provides the necessary abstrac-Interface Options UI Template Response Type Description For applications which are required to display a list of items List Template List Response (in a table view), data will be formatted as list response and will be sent to the client. For any action like adding a new app, removing an app or adding an article to my selection, data will be formatted Actions Template Actions Response into actions response and the status of the action (success/ failure) will be sent to the client. For any grouping based on category (such as alphabets), Indexed List Category List data will be formatted in such a manner where items to a Template Response particular group will be added under that category and will be sent to the mobile client. Media template will display the list of images. The response Media Template List Response will contain the image details in a list format and the images will be bound to the media template.Figure 1 cognizant 20-20 insights 3
  4. 4. Gateway Services External Services SharePoint Services FAST Search Services Client ...... ...... Gateway Services Media ServicesFigure 2tion and a consistency in structure. At the core at runtime to determine the service to be invoked.of the Configurator is the mapping between the Since the services are maintained in a configu-applications, templates and services. Figure 3 rable XML file, it provides the dynamism to changeillustrates the core concept. the actual service implementations.In implementation, Configurator is an XML com- For example, to point to different sources forponent with two major sections: “medical news,” all that the administrator needs to do is to change the URL of the service.• Application: To act as the bridge between the client and service. Principle 4: Loose Coupling at All Levels• Services:To act as the bridge between the Brittleness in architecture can be removed by service and its actual implementation. having a clear segregation of functionality withIn the application section of the Configurator, the a layered approach.7 This will help isolate themapping between the application and the type of changes in specific areas without impactingtemplate necessary for appropriately rendering the whole system. This will help retain the basicthe application will be determined. Each applica- fabric and yet afford easy ways to make changestion will have a template predetermined. The appli- as required. This principle has been put to verycation section will also map the template to the efficient use in our architecture by using theservice. This mapping acts as the bridge between following patterns:this section (application) and the services sectionof the Configurator. In the service name section • Service locator: Pattern to locate the service and delegates to the next layer with greaterof the Configurator file, the mapping between the context.service name and the actual service implementa-tion URL is maintained. This mapping will be read • Service provider: Possibility to decouple the service implementation from service interface.Anatomy of Configurator Backend Service Devices Apps Names Services Names ImplementationsFigure 3 cognizant 20-20 insights 4
  5. 5. • End-point channel: Ability to do service invo- • JSON parser. cations with minimal programming efforts (and • Pagination controller. thus reduce runtime costs). • Log recorder.Service locator: An implementation based ongenerics, service locator is a design pattern that JSON Parserallows decoupling clients of services (described This is primarily used to construct the response.by a public interface) from the concrete class When the enterprise information system returnsimplementing those services. The constructor of a list of news headlines, the JSON parser convertsthe class registers all the available services in a the object into JSON format and passes it on todictionary. A generic method returns a reference the device. JSON parser is also used to read theto the correct implementation fetching it from incoming request details from a mobile devicethe dictionary. The clients do not know the actual through a gateway service.classes implementing the service. They only haveto interact with the service locator to obtain an Pagination Controllerimplementation. Pagination information is defined in the configu- ration file using the number of items per pageService provider: This contains the actual imple- attribute. Based on the value defined in thismentation of the service separated from the attribute, service delivery layer will ensure thatservice interface. Through this decoupling, the only the requested number of items is sent toservice implementation can be evolved without the device by applying filter logic. For subsequentdirectly impacting service consumers. This can pages, the device will send the request with theincrease the amount of refactoring opportunities page number so that appropriate items can beand the range of potential consumer programs retrieved.and corresponding reuse. Log RecorderEnd-point channel: Service host is configured This component will be used across all the appli-by creating an end point specifying an address, cations to capture the status of the incomingbinding and contract. We can merge an address requests from mobile clients and also to log theand a binding with a contract in a channel status of the requests made by service deliveryfactory to create a channel. Having an address layer to other external data sources.(https://<site>/GatewayService.svc), a binding(BasicHttpBinding) and a Contract (IListMan- Principles in Action:ager), we can create the channel: A Scenario WalkthroughBasicHttpBinding basicHttpBinding = Consider an application that bundles allnew BasicHttpBinding(); necessary physician information together. Let us further consider a situation where the physicianEndpointAddress url = new is interested in “medical news.” The requestEndpointAddress(“https://<site>/Gate- object will be created from the mobile client withwayService.svc”); the template, app name, device type and deviceIListManager channelClient = new Cha model information as shown in Figure 4.nnelFactory<IListManager>(basicHttpBinding, url).CreateChannel(); The entry from the figure shows that for medical news application, the UI template to use is theUsing ChannelFactory, we can generate the proxy “List” template. The gateway service request thatbased on the interface definition and the con- is invoked by the mobile device takes the form:figuration. This avoids the need to generate a https://<site>/GatewayService.svc/separate proxy class. This also allows one to code ListTemplateagainst the service interface. This call is handed to the gateway service. ThePrinciple 5: Foundation Service Components “Gateway Service” will locate the right serviceFoundation service components are used across using the configurator. From the snippet of config-the application to support common functionality. urator shown in Figure 5, the service invocation is:Having this, separately, helps to improve main- “http://<SiteName>/SearchService.tainability and reusability for all system-related svc/GetData”changes. The main components in the solution are: cognizant 20-20 insights 5
  6. 6. Sample Request Object for ‘Medical News’ { “UserId”:“MobileUser1”, “ApplicationName”:“Medical News”, “ApplicationId”:“4”, “TemplateName”:“ListTemplate”, “CountryId”:“IN”, “LanguageId”:“EN”, “Params”: [ {“Name”:“ItemsPerPage”,”Value”:”5”}, {“Name”:“PageNumber”,“Value”:“3”}, {“Name”:“SortBy”,“Value”:“MostRecentlyAdded”} ], “DeviceType”:”Nokia”, “DeviceModel”:”8359” }Figure 4From the gateway services, using the principle of • Retrieves the service name and service valueloose coupling, the services are invoked through based on the app name and template name.the service locator and service provider. Thisenables changing the implementations easily • Consumes external services http://<SiteName>/ SearchService.svc/GetData.without making invasive changes. When theresponse is received, using the foundational • Gets the response in XML or JSON format.services of JSON parser, the response is restruc- • Required data is framed and sent in JSONtured to the format determined by the response Format.object for the UI template. • Response data to mobile device in JSON format.The overall architecture with the flow and a The flow sequence can be summarized as below:sample UI is depicted in Figure 6.• Mobiledevice consumes https://<site>/Gate- Client ->Gateway Service ->Service wayservice.svc/lListTemplate. Locator ->Service Provider ->Service ->Gateway Services ->Client• Gets the reference of implementation from service locator. As can be evidenced, the architectural approach• Invokes the actual implementation of the is highly extensible as there is a clear separation interface. of concern between pure rendering of the UIConfigurator File Snippet <?xml version="1.0" encoding="utf-8"?> <ServiceMapping> <Pagination NoOfItemsPerPage="20" /> <VersionInfo No="2" /> <MobilityServices> <Service name="SearchService" value="http://<SiteName>/SearchService.svc/GetData" /> </MobilityServices> <Applications> <Application AppName="Medical News" TemplateName="GeneralListTemplate" Service="SearchService" ServiceType="List" Order="1" /> </Applications> </ServiceMapping>Figure 5 cognizant 20-20 insights 6
  7. 7. Runtime View Device Request (Input from Mobile Devices): App Name, App Id, Template Name, etc Gets the reference https://<site>/ of General Gatewayservice.svc/ List Manager GeneralListTemplate Service Locator Consumes external services http://<SiteName>/ Mobile Devices SearchService.svc/ External Services GetData exposed over Response data to Gateway Services Service Provider Invokes General Internet/Intranet mobile device in JSON format List Manager. Get Response() Retrieves the service name and service value based on the App Name and Template name <?xml version="1.0" encoding="utf-8"?> <ServiceMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <Pagination NoOfItemsPerPage="20" /> <VersionInfo No="2" /> <MobilityServices> <Service name="SearchService" value="http://<SiteName>/SearchService.svc/GetData" /> </MobilityServices> <Applications> <Application AppName="Medical TV" TemplateName="GeneralListTemplate" Service="SearchService" ServiceType="List" Order="1" /> </Applications> </ServiceMapping>Figure 6and the data elements inside the UI. Consider a information sources. The separate rendering ofscenario where a new information source needs UI and data elements within the UI is a powerfullyto be added — for example, “medical videos.” innovative idea that can be put to use in transac-Assume further that the Web service to get the tional applications as well. Similarly, the level ofmedical videos is made available. One can simply configuration-based changes that this architec-associate the medical video information source ture permits can be used where a need exists towith an appropriate service, UI template and the point to different information sources, dependingresponse type in the configurator and it will be on the level of user role.available in the mobile client without any devel-opment efforts. We intend to further our work in the area of build- ing extensible mobile enabling layers that can effi-Conclusion ciently make available the enterprise information to mobile devices.The architectural principles discussed above offera great deal of flexibility in adding new informa-tion sources. The salient benefits of this architec- User Interfaceture are:• Device Agnostism: Decoupled from device and can work with any type of device.• Decoupled: All layers are detached.• Configurable: The display type or service can be changed by invoking simple settings in con- figuration file.• Extensible: New data sources can be added with ease.• Performance: Delivers high performance as layers are designed to do specific tasks.Multinational requirements can also be handledwith ease using this approach by specifying thelanguage and country in the device request;a service mapping in the configurator can becreated for language/country.The architecture can be used in enabling any typeof mobile application from existing enterprise Figure 7 cognizant 20-20 insights 7
  8. 8. AcknowledgmentsThe authors express their profound gratitude to Cognizant’s Saikumar Jagannathan, Chief Architect,for his consistent encouragement. Many thoughts expressed herein have been shaped by stimulatingdiscussions with Srivatsan Nagaraja, Cognizant Senior Vice President and head of Life Sciences, NorthAmerica. We also wish to record our gratitude to Sairamkumar Jeyaraman, Cognizant Vice President, forpropelling us to think creatively.Footnotes1 Karen Church, Barry Smyth, Paul Cotter, “Mobile Information Access: A Study of Emerging Search Behav- ior on Mobile Internet,” Transactions of the Web, Vol. 1, Issue 1, May 2007.2 http://blogs.hbr.org/innovations-in-health-care/2011/03/david-aylward-the-mobile-phone.html, Harvard Business Review blog.3 Yoon-Ho Seol, David R. Kaufman, Eneida A. Mendonça, James J. Cimino, Stephen B. Johnson, Scenario- Based Assessment of Physicians’ Information Needs, Department of Biomedical Informatics, Columbia University College of Physicians and Surgeons, New York. MedInfo 2004.4 http://manhattanresearch.com/.5 FDA regulations on mobile applications, http://www.fda.gov/MedicalDevices/ProductsandMedicalProce- dures/ucm255978.htm.6 http://computeinmotion.com/2011/02/mobile-application-helps-physicians-stop-the-bleeding/.7 Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice, Addison Wesley, 2003.About the AuthorsLavanya Hariharan is a Technology Specialist in Cognizant’s Technology Solution’s Life SciencesPractice. Lavanya is passionate about technology and specializes in Microsoft technologies, mobileapplications, performance optimizations and estimations. She can be reached at Lavanya.Hariharan@cognizant.com.Raghuraman Krishnamurty is the Chief Architect in Cognizant Technology Solution’s Life SciencesPractice. He holds a masters degree from Indian Institute of Technology, Mumbai, India. Raghuramanworks exclusively for pharmaceuticals clients and specializes in mobility, big data and social media. Heis a senior member of the Association of Computing Machinery (ACM) and is based in Chennai, India. Hecan be reached at Raghuraman.Krishnamurthy2@cognizant.com.Baskar Senguttuvan is the Principal Architect in Cognizant Technology Solution’s Life Sciences Practice.He holds a Ph.D. Baskar specializes in software architectures, Java and J2EE-based developments andsoftware development methodologies. He can be reached at Baskar.Senguttuvan@cognizant.com.About CognizantCognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business process out-sourcing services, dedicated to helping the world’s leading companies build stronger businesses. Headquartered inTeaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction, technology innovation, deep industryand business process expertise, and a global, collaborative workforce that embodies the future of work. With over 50delivery centers worldwide and approximately 145,200 employees as of June 30, 2012, Cognizant is a member of theNASDAQ-100, the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performingand fastest growing companies in the world. Visit us online at www.cognizant.com or follow us on Twitter: Cognizant. World Headquarters European Headquarters India Operations Headquarters 500 Frank W. Burr Blvd. 1 Kingdom Street #5/535, Old Mahabalipuram Road Teaneck, NJ 07666 USA Paddington Central Okkiyam Pettai, Thoraipakkam Phone: +1 201 801 0233 London W2 6BD Chennai, 600 096 India Fax: +1 201 801 0243 Phone: +44 (0) 20 7297 7600 Phone: +91 (0) 44 4209 6000 Toll Free: +1 888 937 3277 Fax: +44 (0) 20 7121 0102 Fax: +91 (0) 44 4209 6060 Email: inquiry@cognizant.com Email: infouk@cognizant.com Email: inquiryindia@cognizant.com©­­ Copyright 2012, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by anymeans, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein issubject to change without notice. All other trademarks mentioned herein are the property of their respective owners.

×