Case study: Business project built on the PLASH platform

Case study: Business project built on the PLASH platform

A project has been initiated to build a system that supports customers of a mobile network carrier code named Carrier V (the firm’s real name is confidential). The system aims to support mainstream mobile phones as well as commonly used vehicle GPS devices using Carrier V networks. Fig. 3 shows how various stakeholders interact with the server backed by the PLASH platform. The role of each stakeholder is explained as follows:

 

 

(A) PLASH platform based server: The fundamental architecture is same as the original PLASH platform. Inside this server, there are native PLASH location aware services as well as services for geospatial data I/O and accounts management. Carrier V will create its own services as well as invite business partners to develop and deploy their services. The underlying service bus serves multiple kinds of databases, heterogeneous external services and clients.

 

(B) In-house datastore: This is a set of databases maintained by the Carrier V. The PLASH team has developed efficient geo-queries for PostgreSQL with PostGIS extension while Carrier V has already devised high performance algorithms on Oracle database to satisfy its business requirements. In this situation, system designers need not care about the compatibility issues and they simply install both databases on the datastore.

 

(C) Services provided by business partners: For security, patent, performance or other reasons, business partners may wish to establish their own servers and services. In this scenario, business partners could connect to the service bus and reveal only sharable information. On the other hand, a business partner may also access and chain services provided by other Carrier V’s partners via service bus.

 

(D) Datastores of business partners: For performance reasons a business partner may allow Carrier V’s server to access its database.

 

(E) Application server of Carrier V: Application server fulfills the requests from standalone software or web applications (the stakeholder F and G as depicted). The requirement of having separate application servers is nominated due to budget constraints and the need of workload distribution. Extra costs would arise if Carrier V spent the effort to port sophisticated content provisioning systems that had already been implemented in other languages and architecture. In addition, mirror servers are needed in local cities or townships to provide a good quality of service. The design of PLASH platform addresses such requirement well and has helped Carrier V integrate its legacy systems.

 

(F)(G) Mobile and PC applications: Various versions of value added software utilities are developed by Carrier V to serve all of its subscribers.  Most mainstream operating systems are covered as shown in Fig. 3. PC or mobile HTML versions are also available for unspecified systems. PC software may use HTTP protocols or proprietary protocols and message formats. By installing corresponding transports and transformers, the PLASH-based server supports all of them.

 

Here is an example scenario showing how all stakeholders collaborate together. A customer uses mobile phone (F) to continuously updating her location with server (E and involves A, B) while receiving information regarding nearby tourist attractions from server (A and involves B or D). At some point of time the server (E) pushes advertisements to the mobile phone (F) to promote on-sale items at nearby stores. The advertisements are generated by business partners (C). On the other side of the globe her parents (G) use desktop utility to know where their daughter is (done by A) in order to eliminate the anxiety and have a nice sleep.

 

The advertisement service in the above scenario can be created by chaining few services rather than programing a new service. For example, the business partner would write simple router configurations to direct a message to a service that generates a list of all nearby stores using k-NN queries. Then direct the message simultaneously to a service that finds on sale items and a service that shows store information and directions. The message carrying aggregated results is then directed to clients.