A lot of my work in the past decade has focussed on endpoint driven systems, e.g., peer-to-peer Internet telephony (P2P-SIP) [1,2] for inherent scalability/robustness, Rich Internet Applications for web video conferencing [3,4], and more recently, resource-based software architecture [5,6]. In this article, I emphasize the importance of such systems, and differentiate them from other system architectures in the context of real-time communication.
Endpoint driven systems are those where most, if not all, of the application logic runs in the endpoint. Such an endpoint may use external services or other endpoints, e.g., for storing persistent data, redundancy, or traversal through restricted networks. If the application logic such as conference membership or chat interaction is abstracted as a program function that works on some data or interacts with other functions, where does that function run? Does it run in the endpoint or some server?
Client-server systems are examples of distributed systems that have clients connecting to servers over the network for accessing some data or service. Depending on the application, such systems can be endpoint driven, e.g., emerging HTML5 applications often use a web server just to host the web files, but perform many user interaction logic in the browser client. A client-server system has different roles for the two communicating entities. This is unlike a pure peer-to-peer system where every client can also act as a server when needed, and collectively they serve each other in the application.
Service oriented systems are those where services are clearly identified, and are accessed in a loosely coupled manner using well defined interfaces. Depending on the type of service and the interface, a communication system can be both endpoint driven and service oriented, e.g., Vclick [7, 8] is a web-based video collaboration application that uses a resource service with well defined APIs for shared data storage and notifications, but still runs all the application logic in the browser endpoint. RESTful client-server architectures further encourage pushing the application logic in the client.
Loosely coupled systems separate the different modules or elements so that they can be easily replaced or failed over. Fault tolerance is a big objective of such systems. However the terminology is tangential to other terms I mentioned, and can be applied to those systems. A SIP phone client and SIP proxy server are by design loosely coupled. However, often times a provider requires a particular vendor's phone or device, making it tightly coupled to the service. Similarly, existing client-server or service oriented web applications are often tightly coupled - the HTML/Javascript must use the web service on that particular web server.
Data driven systems are those where focus is on large set of data, and one writes modular and small pieces of application logic or functions that operate on that data. If the application logic runs in the endpoint, such systems can still be endpoint driven. However, existing examples of data driven systems are often server or cloud based. In a communication context, such applications are usually for offline data analytics, and not for real-time communication.
Data oriented systems (or applications) are those that separate the data and the application logic, and more importantly, allow plug and play of the two elements. For example, ability of a communication system to easily replace the user accounts and contacts data from one social network or directory to another, or ability to use a third-party chat application using existing user accounts and contacts. Many web applications are internally data oriented, but such plug and play are not exposed externally to the end users. (Data oriented design or programming is completely unrelated to this, and is about optimizing the data layout, unlike object oriented design or programming.)
A personally controlled system takes the data oriented application to the next level, where the end user is in control of her data, and can potentially use any application to work on her data. For example, user could manage and store her own user account information, contacts and chat history wherever she wants, and could use any compatible user agent or softphone to work on that data and to connect with her contacts, while temporarily giving access of her data to that user agent. If an application that uses users' social data becomes obsolete, it does not render the social data itself useless - users could easily import their data to a new application or platform.
Rich Internet Applications are usually web applications but behave similar to desktop applications, and are often delivered via browser plugins or extensive HTML5 features. Thus, most of the application logic runs in the endpoint, and are often also classified as endpoint driven systems. However, due to the legacy use of the terminology, even a simple Flash application that displays only a phone dialpad, but runs everything else in the server is mistakenly call Rich Internet Application.
Thin client refers to hardware systems with limited capabilities, that often use external server side systems to fulfill many of the application demands. In the communication context, a thin client system puts very little load in the endpoint device, and performs bulk of its functions in the server. However, due to the legacy use of the terminology, some web based rich communication applications, that are delivered via a browser, and run within the browser, are also mistakenly called thin client applications. Nevertheless, thin client often means thick server, and unlike endpoint driven applications, often requires expensive servers.
As an example, Vclick can be categorized as endpoint driven, client-server, loosely coupled, data oriented, and rich Internet application. Strata is endpoint driven, client-server but also peer-to-peer, tightly coupled, service oriented system.
There are other terms that are often used in the context of communication systems. For example, a "managed" service is typically used to refer to a telecom style billed service in which the service provider controls many aspect of the end user behavior, e.g., who the users can call, who they can add in their contacts, etc. For example, call blocking can clearly be an endpoint service, but is often implemented and marketed as a managed service. Many modern web communication applications controlled by a single provider or website are examples of this. Integrated platform or ecosystem is often used as an euphemism for such single vendor dictatorship. As the user demands grow and the number of diverse systems appear, such systems then become open to federation or one-on-one integration with other big players. A federated system is often an euphemism for a closed and/or proprietary system that selectively decides to collude with one or more other such systems.
So what are the benefits of endpoint driven systems? They are inherently (or can easily be made) scalable and robust. The scalability is usually limited by the service, and the lesser the dependency on the service, the easier it is to scale and failover. Traditional software often followed the endpoint driven, personally controlled approach, e.g., an app to edit your files or to send emails irrespective of where or how the data was stored or obtained. With emerging trends in web apps and walled garden approach of social software, systems became more "managed", data controllers and service oriented. Typically, an expensive on-premise server or cloud hosted subscription based service is a sign that it is not an endpoint driven system. With the emergence of mobile apps, endpoint driven systems are becoming more popular again.
Endpoint driven trait is not protocol specific. People familiar with public telephone systems know that endpoints or phones there are very dumb devices, and most of the intelligence lies in the network or servers. The Internet, with its end-to-end approach, attempts to change the basic notion, by keeping the intelligence in the endpoints. Ideally, a failure in the intermediate router or device does not break the end-to-end transport session for any app such as file transfer or remote-login. The Internet communication protocol, SIP (session initiation protocol), was invented to be end-to-end, with lightweight (and sometimes optional) servers. However, business constraints have forced many real-world deployments to be largely single provider systems - although all the user devices and services use SIP internally, it won't work outside the ecosystem, i.e., the end user must register her user agent with one service, and can only talk to other people who are registered only with that one service.
As another example, in SIP-based IMS architecture, a fully compliant SIP endpoint is treated as a very dumb end device, that must connect with only so-and-so IP addresses, and must only use so-and-so ways of reachability. Many of the end-to-end capability of the SIP terminal is constrained if the network element does not "support" that feature by passing that through various intermediate proxies. For example, applications such as file transfer, picture sharing or even text chat can be implemented end-to-end in SIP by just conveying that session information in the SDP. As long as the two endpoints understand that, and intermediate proxies do not mangle the session description in this endpoint driven system, things often work without problem. Good luck doing this with an IMS compliant system!
With emerging WebRTC, the trend continues to grow, as each website now becomes its own VoIP provider, preventing its users to talk to another from within that website. Compare this with a SIP user agent inline with the original endpoint driven vision of SIP, which could register with one or more third-party SIP services, talk to people on any SIP address, and incorporate new features such as video, text chat, file sharing and even device control, without depending on the intermediate servers. Independent innovation is the real power of endpoint driven systems.
The services, tools and applications should be independently developed to promote innovation in each dimension. Imagine what would have happened if every email provider had its own email client, or allowed sending emails to only its own registered users. Or imagine what would have happened if every business developed its own web browser and server applications. In the world of communication, we are essentially going on that route - islands of highly controlling providers, who manage their own communication apps, have their own communication services, and control every aspect of communication among their users. There are solutions emerging to solve this problem such as the endpoint driven approach proposed by me [9, 10], but one should avoid the problem altogether in the first place.
The endpoint driven systems, when combined with other virtues of loosely coupled, data oriented, and personally controlled system designs, one can truly create a free communication system - one that is free to use by anyone, one that is free from control of a single provider, one that is free to evolve without unnecessary constraints - similar to how email and originally web evolved. What are the building blocks of such a system? An independent data storage that allows the end user to store, access her data, get notified when something changes, or when someone views her data, and permit her data to be selectively used by certain applications. A marketplace of endpoint driven communication applications that uses this data to enable end-to-end secure and reliable communication and collaboration. And finally, the underlying network infrastructure that stays out of the way of the endpoint driven applications.
In summary, things to take away:
- Independent innovation is the real power of endpoint driven systems.
- Ecosystem is an euphemism for single vendor dictatorship.
- System virtues: endpoint driven, loosely coupled, data oriented, personally controlled.
- System vices appear when there is overlap in services, tools and/or apps.
No comments:
Post a Comment