PROVIDER ACTIVITY SUBSCRIBER MODEL

THE PROVIDER-ACTIVITY-SUBSCRIBBER MODEL I was faced with the challenge of creating an online solution for e-learning. Such a daunting task could not be done in a hurry and of course there is the faster and maybe wiser approach of adopting existing frameworks. Sometimes however, developers are forced to provide clients a bespoke application. Such was my situations that lead to the Provider-ActivitySubscriber (P-A-S) model. The design concept in P-A-S is aimed at solving a range of business problems comprising of three business components namely, the providers (P) of a need or service, subscribers of the provided service (S), and the service itself (A). Before delving deep into the P-A-S concept, I think it will be helpful to give an overview of this concept using an example. Assuming we have our online learning platform with the primary focus of providing learning resource for registered students, alongside other services such as networking with other users. A large amount of the system users will be students; another could be the course assistants and lecturers. The user list will also likely constitute of administrative roles for institutions providing the learning resource and maybe inspectors of the course. Broadly speaking, we can safely assume two users of the system exist: that which constitutes mainly of STUDENTS and users which forms staff of INSTITUTIONS. For simplicity, we represent the later as Lecturers. With the above classification, we can ask “what functions are available to each category of users?” Our dummy list will have the following: STUDENT’S LIST 1. Register online for a course 2. Take lectures online 3. Take class quizzes and assignments 4. Submit assignments 5. Contribute to blogs LECUTURER’S LIST 1. Register as a lecturer online 2. Provide lecture resource or materials online 3. Provide assignment and class quizzes 4. Contribute to blogs 5. Moderate blogs Looking at the functionalities available to the user groups we can deduce that the students rely on the lecturers to get their functions done, that is, without the lecturer providing the student certain tasks, there will be nothing for the student to do. If we consider these functions as ACTIVITIES, then the students’ ACTIVITIES are based on the lecturer’s ACTIVITIES. We can further extend our thoughts to state that an ACTIVITY has both a student and a lecturer responsibility. In essence, we do not consider the Students’ ACTIVITY as being independent and separate from that of the Lecturer; rather we see them as the same “coin” with two faces. This dependency is foundational for the ProviderActivity-Subscriber (P-A-S) model. The model in effect addresses needs for a Provider (a lecturer in our case) supplying a set of tasks (Student’s activity) to be accomplished by a Subscriber (Student) in our example.

Provider Activity Subscriber Model by Aniefiok Friday is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Based on a work at http://codeskol.com/blog/?p=33.

Fig. 1: A Provider offers Services to Subscriber From the above example, we have obtained a very simplistic model of the business domain in which the entities (Student and Lecturer) has clearly defined relationships. These relationships are based on the activities of each entity. Alternatively, we can say each entity has clearly defined activities which connects it to other entities. We can extend this model to also work for cases where we have more than two types of entities. As long as these entities have their activities clearly defined and the respective subscription rules are well captured then the P-A-S model can handle the business process of the domain in view. From this, we can postulate the following:  A Provider can be any business entity or group of business entities which initiates a Service. Real life examples can be a lecturer giving assignments, a tour guide leading a group, a salesman giving discounts, a charity organization giving away some registration offer.  A Subscriber can be any entity or group of entities which patronizes the services of a Provider. The Subscriber in a business scenario may be registered customers, a public user of a service, a member of a charity organization enjoying certain benefits. Further consideration of every day businesses will further raise questions on the nature of the subscription service and how the Provider and Subscriber perform their roles. For example, does the Provider simply make available a service and knows nothing about the Subscriber? Will Providers be demanded to be actively engaged with the Subscribers as they perform their subscription duties? These various scenarios lead to more postulations such as: 

A Subscriber may be actively engaged with set of tasks or duties assigned to them by a Provider or Service. Let us call a scenario where the Subscriber must be actively involved by performing listed tasks. For example, a student subscriber must take some quizzes and do assignments to remain a student. We call such subscription ACTIVE SUBSCRIPTION in the P-A-S model. On the other hand, there exist instances where a Subscriber may not have set of task to perform while still accessing services from a Provider. An example could be an organization with free membership where the members are do not pay dues, fees, or do any such but are only required to register. Such an association may not be common but for the sake of a more elaborate model, let us consider such subscription as PASSIVE SUBSCRIPTION in our P-A-S model.

Provider Activity Subscriber Model by Aniefiok Friday is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Based on a work at http://codeskol.com/blog/?p=33.



Every subscription will be guided by set rules which defines who a Provider and Subscriber is. These rules will also govern other aspects of the subscription like who can subscribe to a service, the rate of accessing benefits of the subscription, the nature of the tasks for subscribers etc.

With the above, we can consider the software design for our P-A-S model to comprise of entities as Providers and Subscribers being captured as objects in our business domain. We have subscription rules which can be captured as functions or operations in our domain. In an Object Oriented Programming style, these rules could be interfaces implemented by various Service Objects or Abstract classes. Finally in our model, there exist the need to have Tasks of the Provider and Subscribers. The Tasks object will hold reference to entity which performs it, example a Subscriber or Provider. An alternative way of viewing the Task object is to see it as a composite part of the Provider or Subscriber entity. In this way, a Task is always associated with its respective owner. The design consideration just listed is a very simplistic way of viewing the domain. In reality, Task though associated with a Subscriber or Provider is closely associated with a Service and as much as possible should be loosely coupled from other objects. The Provider offers a Service by performing a Provider’s set of Tasks. On the other hand, a Subscriber enjoys a subscription by performing a Subscriber’s set of Tasks. If we assume our Providers do not need to know the operations of the Subscriber which is typical in most cases, we can still obtain knowledge of both the Provider and the Subscriber by looking closely at the associated Tasks of both entities. In essence, our design will be such that we consider Providers in isolation from their respective Subscribers of their services.

Fig. 2: A Provider is must perform set Tasks before a Service can be made available The same will hold for the Subscribers which will be considered separate from the respective Provider(s). Doing this, we learn more of the Provider only through defined Tasks associated with providing any given Service and learn of the subscriber by inspecting Tasks required for enjoying selected Subscriptions.

Provider Activity Subscriber Model by Aniefiok Friday is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Based on a work at http://codeskol.com/blog/?p=33.

Fig. 3: A Subscriber may enjoy a Service after meeting set requirements The resulting design has the Activity (which is a wrapper for the Task) at the center of the Provider and Subscriber. This approach I believe is only natural for most of the rules governing the domain are defined by Activities and not by the nomenclature of the Provider or the Subscriber. Another benefit of having the Activity at the center of our model is because an Activity centered approach is more likely to ensure rules are maintained. If we look at our hypothetical school example once more, we have a challenge of managing our school and keeping it very efficient. We can do this by inspecting our various Subscribers and Providers - in real life, this could be by always contacting Students and Lecturers. Alternatively, we can do the same by asking “What tasks has been done” by our lecturers and students? It is safe to say if all students perform their tasks and all lecturers do same, our overall system will be efficient for the set goal in which it was designed. By monitoring Tasks, we invariably monitor both the Subscriber and the Provider. Thus, the Activity which embeds our various Tasks becomes the center of our design model. Another benefit of a Task centered P-A-S model is that it enables application developer focus on the vital components of the domain or system from inception. Once the P-A-S engine is working, then secondary features can be added without loss in business service or functionality as provided by the Tasks. Building a generic P-A-S model enables rapid development of business application in which users are expected to perform tasks or assignments determined by a Provider. These tasks by the user can be watching a video, filling an online form, making a video chat or any such activity. It essentially requires developers to deploy a platform from which Activities are registered and then assigned to the subscriber or made available for subscribers. A variety of tools may be used to achieve the same design concept however the benefits remains the same: one can simply monitor and manage a domain by managing the set Tasks for both Providers and Subscribers.

Provider Activity Subscriber Model by Aniefiok Friday is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Based on a work at http://codeskol.com/blog/?p=33.