End users require networked applications that are easy and intuitive to use, have fast response times, are secure to use, utilize several forms of media, and connect to the surrounding ecosystem. User interface design, availability, scalability, security, integration and general complexity of modern rich applications are major concerns for companies that provide services to their customers. The 10Duke SDK (SDK) addresses these concerns, providing a consistent package with simple interfaces for building systems that are flexible and easy to connect with real-world environments.
The image above depicts software architecture of a typical application built using the SDK. It delivers a working system that can be connected using a web browser out of the box, but more importantly, any component around the depicted SDK application is scalable or can be freely changed. The ability to rapidly build prototypes and campaigns with the SDK is a result of our design principle that an enterprise class SDK must be delivered with working default components and configurations.
End users are the most important part of a social application; the application is built for the end users, and they ultimately make the application what it is. Commonly, end users use browsers for interacting with the application, but in many cases mobile and desktop clients are relevant and can be used to improve and enhance the end user experience.
The SDK delivers simple, generic, extensible and flexible solutions for major challenges of modern rich networked applications, always keeping in mind that applications may start small and grow to serve large end user communities. The SDK contains components that work seamlessly together, scale as necessary and make it simple to implement features including persistence, media storage, content delivery, media processing (transcoding, image scaling etc.) and distribution. Please note that this only scratches the surface of the SDK, see our documentation for more information.
Many important features of the SDK are self-contained and use standard simple types in the APIs. For instance, the SDK media processing toolchain or the storage provider can be used independently, without using other SDK components.
In order to fully utilize the SDK, it is important to design and implement an object model (domain model). The object model describes entities, attributes and relationships in the application's domain of interest. In the networked world, there are many concepts that are similar, de facto standard approaches, or that have many common factors across different services. For instance, in most social services there is a concept of a user profile. There are variations in implementations of the concept, but for most parts different implementations are pretty similar. There are also several specifications such as OpenSocial and Facebook Graph API that define these kinds of object models.
The SDK comes with an extensible object model with ready to use objects for many common cases in the social networking and rich media services domain. Developers can model users, user groups, roles and permissions, privacy settings, relationships, media entries, user communication etc. with the provided object model classes. Existing classes can be inherited and new classes can be defined to support specific requirements.
Within the SDK the object model is core to the model part in a model-view-controller (MVC) architecture. Commands (implementation of the command design pattern) are used to encapsulate application logic operations in a distributed manner.
View is usually rendered by UI engine (see the image above). Controller consists of servlets, and applications may also use e.g. JSP (JavaServer Page) endpoints to access the controller.
Rather than enforcing MVC, the SDK naturally directs developers towards MVC, allowing different flavors in MVC implementation.
Networked applications often need to handle large amounts of users that may access the application anywhere on the planet. Implementing and running this kind of application cost efficiently is difficult, and there is no single solution that would be best for all cases. Clouds may be used to gain flexibility and to allocate resources efficiently, Content Delivery Networks (CDNs) may be used to achieve reliable and fast delivery globally, and different storage systems may be used to store high volumes of files.
Within the SDK, we believe in flexibility and ability to react quickly to growing demands or other changes in requirements for the application, and making all of this as simple as possible for developers and system administrators. Developers can start by serving everything from a single server (that may be anything from a dedicated server to a cloud server instance). If and when limits of the single server are reached, actions to be taken depend on the nature of demand on the system, for instance:
Scaling horizontally, hooking in a CDN, changing the used storage system, and delegating media processing to dedicated systems are all examples of scaling strategies supported by the SDK.