With the apparition of the smart-phones,a huge quantity of markets for the applications have also appeared,but within, the suppliers varie from communication enterprisers,mobile producers to platform producers.To share and better utilize the contents of the mobile applications, the communication enterprisers in world-wide and the native mobile producers have organized WAC.Also to resolute the problem of producing different applications for each other platform, a new market focussed on web-applications which didn’t have much relations to the application platform has shown through.But today ,because WAC has been to much focussed on the technologies,not only the communication between the creators wasn’t stabilized and utilized thoroughly but also cause Mac OS and Google OS have developped very quickly,WAC has met it’s failure.There are native app stores , one which works after installation like Google or Apple app store, and another , installed-web-app store which is produced based on the standard language and which works in the web browsers like HTML5, Javascript, CSS3.To support every smart phone which has plenty of differences in the OS system and the versions ,not only installed-web-application which uses the standard function of browsers has been created ,but also stores of applications which are based on websites like facebook were created.
In the case of installing the application through the website, if we could install the application having no concern with the browsers,there is no reason for the producers to create applications for each different browsers. For that,OWS should engage web application stores,to make any applications to work in any browsers having no matters with platforms.Therefore this study will be addressed to the changes of the detail Architecture of OWS and a standard Manifest recommendation or the lifestyle for realizing engagement.
And then comparing with last year’s data,we will analyze if there is any difference in the demand of Telco’s Application Store.Last year we have seen the demand of the engagement between the installed-web-application stores and also seen the elements that we needed for the scenario, but this year we will classify the reference model of OWS or the studies addressed to standard Manifest demand. Also comparing with last year, this study will contain the classification of comparison between Mozilla,W3C and Chrome’s manifest and comparison of web stores.
This OWS model is based on the requirements of OMA's TAS standards and its extended model for interoperation between OWS. Storefront to provide direct services to clients is composed of SAM(Shared App Management) for interworking, Policy module related to policy and Policy Provider.
;)
;)
Storefront module is consist of A storefront module is consist of five submodules(App Repository, User Account Repository, App Manager, Account Manager and SAM Adapter).
Application Repository is the repository which stores information about the remote applications. User Account Repository is the repository which stores information about the remote user(and developer).
;)
SAM (Shared App Management)is composed of Module of RemoteStore Connecter and 2 storages.
RemoteStore Connecter is a element which communicates with another engaged store by the requirement of the SAM Adapter of the Storefront.It manages not only the receipt and transmit of the application and the list of applications ,but also it can require inspection to the Policy Module.It also controls the operation to add,delete,modify the value of the storage.
App List Repository stores the application list engaged to the Remote store or produced by the OrigineStore.The Storefront recieves a reference ID of the application by the App List Repository and demands to another store to engage.App List Repository includes also the lists which weren’t accepted by the Policy Module.Also RemoteStore URL List Repository keeps the URL of the other engaged application stores which is one of SAM’s element and which demands engagement.
;)
Policy module that perform application inspection have Compare Unit that receives application ID by SAM and performs inspection and Policy Repository stored policy. Compare Unit executes inspection in connection with interworking whether it can be sent to another store or received applications can be registered and according to approved and unapproved information deliver the SAM.
;)
In order to interworking, each store usually interwork application list. Application developed OriginStore store list in the application list repository in SAM. RemoteStore Connector interwork list to each store refer to the URL of promise interworking from RemoteStore URL list repository. The interior RemoteStore connector of RemoteStore SAM is delivered application list and store in application list repository.
;)
After installing the list to the RemoteStore,utilizing SAM ,Remote Storefront requires to the OriginStore the applicalition that needs to be engaged.Before transmitting this application,OrigineStore demands inspection to the Policy Module.In this case it checks the adaptability of the version or the status for the installation.After inspection, it is sent to the RemoteStore and SAM demands again an inspection for the installed application.If it passes every inspection this application would be installed in the application storage of the Storefront and finishes it’s process.But if it doesn’t it would be saved in the rejected application list.
;)
In the application interworking process, RemoteStore receive application and request policy to Policy module. Policy perform at policy module in Policy, if It is not suitable for Policy, application registration of Storefront may be refused. Rejected application stored application list reposotory in SAM, RemoteStore connector request repolicy to Policy module regularly. After repolicy, The results of application to grant or deny pass to OrignStore, it delivere to developers through Developer Support finally.
;)
After linkage to register OriginStore about the application being rejected, RemoteStore periodically to request the Policy module to re-audit. RemoteStore inappropriate application of the policy had been changed or modified, the elements can be permit the re-audit, which passes the information to the SAM is the Storefront to register the application has been completed and forwarded to OriginStore to register. OriginStore deliver results to developers using the Developer Support.
;)
In the event that a client purchases an application at ‘RemoteStore’ after the application is transmitted from ‘OriginStore’ to ‘RemoteStore’, the account manager earns a specific percentage of commission on the sales. Afterward SAM adaptor transfers the rest to SAM, and SAM does the same to ‘OriginStore’. At this point, there are two different ways depending on store policies; one is transferring money every time clients purchase the application, and the other is accumulating money for a certain period of time and then transferring periodically. After the amounts are transmitted to ‘OriginStore’, the developer gets proceeds through ‘Developer Support’.
;)
;)
If the application includes malicious contents or errors, the clients can send malicious application report or bug report to ‘Storefront’. During this procedure, SAM adaptor transfers the information to the developer and to ‘RemoteStore’ that is connected with the application after the client at ‘OriginStore’ send the report to ‘Storefront’. When it comes to a simple bug, it can be finished up with informing the developer of it, but if the bug goes against the policy, the application can be invalidated.
;)
If the application which is transmitted from ‘OriginStore’ includes malicious contents or errors, the client at ‘RemoteStore’ can send a report to ‘Storefront’. After receiving the information, ‘RemoteStore’ transfers it to ‘OriginStore’ and ‘OriginStore’ does the same to the developer of the application. Also, ‘OriginStore’ transmits the bug report to each ‘RemoteStore’ connected with the application through SAM.
;)
;)
R.1.1 The system ispect and test about application submitted by the developer.
R.1.2 The system should support to enable modify and update about application submitted by the developer.
R.1.3 The system should support registration about application completed instpection.
R.1.4 The system should support deletion and stop posting about registered application for developer.
R.1.5 The system can be stop posting if registered application is Malicious application.
R.1.6 The system should reflect about application updated for complete.
R.1.7 The system is capable of update and deletion about application completed interworking.
R.1.8 The system is capable of posted on hold about inspection results of the updated appliction.
R.1.9 The system can be informed update, posted on hold and deletion of applicaion to the remote store.
R.1.10 The system should reinspection and testing if developer is modify aborted application.
R.2.1 The developer may request the deletion about submitted application.
R.2.2 The developer may request the update, stop posting and deletion about registered application.
R.2.3 The developer capable of update cancel or deletion about updated application.
R.2.4 The developer may request withdrawal about application completed interworking.
R.2.5 he developer can modify and delete about aborted application.
;)
Beneath there is a drawing of Use Case Diagram based on the demand of the Lifecycle.At first, concentrated on the store ,there were too much differences so we added Developer Managerand. Secondly, the UseCase of the Developer wasn’t appropriate so we also added the Developer Manager and the Store Manager.Developer Manager is the actor who manages the UseCase of the Developer Support and the Store Manger does the same role for the Store system.
The UseCase of the Developer Support is composed of immediate UseCase because it is thoroughly related with the producers.For example Submit application, Modify submitted application, Remove registered application, Update interworked application, Remove interworked application are connected with Developer and Invalid malicious application, Audit submitted application, Test submitted application are connected with Developer Manager.Especially Invalid interworked application is related to both actors.
UseCase of the Store which are Invalid register application, Reaudited modified application in invalidation, Test modified application in invalidation, Support updated application, Register audited application connects to the Store Manager.
;)
The diagram below indicates all the states that web application can have. First of all, the two ovals are the final state of application and the blue ovals are the states from TAS structure which are the basic outline of TAS. Moreover, dotted lines show the messages. When application is in the certain state, it sends messages to other stores and affects them. The conversion of state is marked in an arrow and its actor is also indicated next to it.
Firstly, it starts from an offline state in an origin. When a developer submits an application, it undergoes a submitted state and goes on to an audited state after an examination. During audited state, it can fall into 3 states; Rejected, Tested, and online at origin. In rejected state, the application is refused due to the policies and undergoes to a final state. Tested state is when the developer requested a test for application in audited state. Particularly, application in audited state can move on to online at origin state since Tested stage is not mandatory. Finally, online at origin state is when application is posted and valid. If the developer ceases to post the application, the state changes from online at origin to invalidation and when it is canceled, it returns to normal. On the other hand, if the developer deletes the application in invalidation state, it goes on to removal state.
When an origin store receives an interlock requesting message from a remote store, application in online at origin state alters to sending to remote state. In this state, application is sent with ACK to the remote store and undergoes to a received state. When examination on application is completed, the application enters to audited at remote state. And if it is rejected, it goes on to rejected at remote state which is the final state. However, if it is not refused and passes, the application is posted and turns into an online at remote state.
When the message that implies the completion of interlock is sent to origin store while the application is in online at remote state, the application alters from sending to remote state to Transmitted state. Transmitted stage means the application is sent and available in remote store. First of all, the application can turn into 3 different states; Updating, Invalidating, and Invalidated by store manager. Invalidated by store manager is when application is inactivated by a store manager, and the developer changes the application state to updating state to update the application in the remote store. In Updating state, when other store requests the update, the update requesting message is sent to the remote store. Application in Online at remote state receives the message and goes on to updating at remote state and goes back to online at remote state when the update is over. Also when the ACK about the update completion is sent to origin store, the origin store restores the updating application to the transmitted state.
If developer wants to stop posting the application, it changes into invalidating state which is the state when a posting suspension message is sent to other stores. Remote store that received this message converts the state of application from online at remote to invalid at remote and sends the message mentioning that the state conversion is completed in the form of ACK. When ACK is received, the application’s state changes in to invalidated state and it further undergoes alteration into 3 different states. Firstly, Updated in invalidated state is when the developer updates the application which is invalid. The application remains in this state regardless of the repeated updates unless it is valid. When the suspension is cleared, the application state changes into validating updated app in invalidated state. Application updated in this available situation sends the message about the activation to the remote store. When an application in invalid at remote state is updated, its state is altered to updated in invalidated state at remote and as it got a message about it, it is converted in to online at remote state. Also, if the origin store receives the ACK about this, the state changes from validating updated state app in invalidated state to transmitted state.
Changing from Incalidated to Validateing app in invalidated state, The developer moves stop posting application by making vitalization. At this time, It send a message disabling an application to release to the RemoteStore. RemoteStore received this message back from Invalid a Remote to Online at Remote again. After returning, ACK to complete the activation sends to OriginStore, OriginStore go in to the Transmitted State aboriginally.
Finally, if the developer delete an application state of Invalidated, It return to Removing state. Delete request message send to RemoteStore because they Removing is state of remove the requesting state the other stores. RemoteStore received this message, after delete the application of Invalid at Remote, changes Removed at Remote such as final state. Once this is done the ACK send to OriginStore, OriginStore received it move to Removed state such as final state.
;)
In 'Application Linkage Scenario', Developer Support OriginStore appear on the left side of the object and the 'App at Origin', and the status of the application in the right side RemoteStore App at Remote object will be represented. First, the application in conjunction OriginStore before posting Developer Suport to the interchange between the App at Origin takes place. And Submitted, Audited, Online at Origin last state change. When the request is in conjunction RemoteStore Sending to Romote state change. And so it comes to pass RemoteSotre Received, Audited at Remote Online at Remote state after state changes. Origin of sending a message that completes Trasmitted condition exist.
;)
In 'Application Delete Scenario', App at Origin exists in a state of 'Invalidated' at first. The Storefront Removing a delete request comes to the state and then to the transfer process, which is reached via a Remote, App at Remote Invalidated at Remote's status was initially after receiving the request, the state is changed to Removed at Remote. This transfer process is complete, the message is delivered to the Origin Removed state has changed.
;)
In ‘Application Invalidation Scenario’, ‘App at Remote’ exists in a state of ‘Transmitted’ at first. After receiving a request for deactivation from ‘Storefront’, it changes into a state of ‘Invalidating’ and transferred to ‘App at Remote’ following the transmitting procedure. In the stage of ‘App at Remote’, it exists in a state of ‘Online at Remote’ at first, and it changes into a state of ‘Invalidated at Remote’ after receiving the request. After all, it goes back to ‘Origin’ and change status from ‘Invalidating’ to ‘Invalidated’.
;)
In Web application stop posting Scenario, App at Origin exist Transmitted state in the beginning. At this time, When it receive a disabled request, it changes Invalidating state. After the transfer process it moves to App at Remote. In App at Remote, it is Online at Remote at the beginning and changes Invalidated at Remote state for request. Again, go back to the Origin, it changes from Invalidating state to Invalidated state.
[1] OMA, Telco's Application Store Draft Version 1.0 http://www.openmobilealliance.org 2012.05.24
[2] Samsung Apps: http://www.samsungapps.com
[3] LG SmartWorld: http://kr.lgworld.com
[4] Pantech Appsplay: http://appsplay.vegalive.co.kr
[5] Amazon Appstore: http://www.amazon.com/appstore
[6] SK Telecom T Store: http://www.tstore.co.kr
[7] KT Olleh Market: http://market.olleh.com
[8] LG U+ Appmarket: http://ozstore.uplus.co.kr
[9] Naver N Store: http://nstore.naver.com/appstore/android/home.nhn
[10] Windows Marketplace: http://www.windowsphone.com/ko-KR/marketplace
[11] RIM Blackberry App World: http://appworld.blackberry.com/webstore
[12] Chrome web store: http://chrome.google.com/webstore
[13] Firefox Marketplace: https://marketplace.firefox.com/
[14] Facebook Appcenter: http://www.facebook.com/appcenter
[15] Chrome Manifest: https://developer.chrome.com/apps/manifest.html#overview
[16] Firefox Manifest: https://developer.mozilla.org/ko/docs/Apps/Manifest
[17] Wiki Manifest Comparison: http://www.w3.org/community/webappstore/wiki/Manifest