As Software Architects, our job is to build applications for our clients ensuring that not only are the business requirements met, but that resulting systems are stable, reliable, scalable, maintainable, available, and so on. These “qualities” of good systems are enormously important to have baked in from the beginning, as adding any one of these qualities after the system has hit production is daunting at best. On top of that, we need to ensure that development tools and environments support automation, testing, versioning, multi-member and even distributed teams. The bottom line is that modern software systems require more infrastructure than ever before. Centralized logging, consolidated configuration, health monitoring, database integration, compatible web and client UI frameworks, are just a few of the essential system components. Not to mention SDLC elements such as continuous integration, branch-able source control and build systems, automated testing, automated deployment. Most commercial software applications today have adopted sets of open source or retail software components over time that implements the facilities which lead to this Quality of Service (QOS). If you have been in the business for a while and have either built or worked on systems that have these qualities, it’s easy to take these things for granted. However, if you are starting something new, it’s a big job.
It’s impractical to write custom code for all these QOS elements so one must select, configure and integrate best-of-breed open source or off-the-shelf software packages. Note the emphasis on “integrate”, as it’s not always just about picking the most popular package but how that package works with the rest of the packages you’ve selected, i.e. your “software stack”. Several years ago, I noticed that every new system would take longer and longer to get all this in place. Mostly a cut-and-paste operation, it was tedious, error-prone, and worst of all, the client didn’t see the value. There are many decisions to be made. Which logging framework? Which dependency injection framework? What database, ORM and so on. Complicating matters are the dependencies of the selected components. What .Net Framework or Java version? What are the versions of other shared dependencies? It all has to work together. For components that do not directly impact a competitive advantage, the decision on which brand or version of a core service component to use doesn’t matter as much, as long as it’s there. So for the most part, it matters more on 1) whether the package is compatible and 2) on which packages you and your teams are most familiar with and know how to configure and use.
So what is Topics Platform? Topics Platform is first and foremost a platform to build commercial software applications that inherently contain important QOS elements. It’s a core collection of specific package choices that I have made, integrated and tested over years of development. It’s an integrated software stack. Building on the core QOS elements, I’ve also selected UI frameworks and packages to assist in bootstrapping Web Sites and Web API Servers as well as a WPF client based on the MVVM pattern. Beyond the Presentation Services, there are Application and Product Services which provide Token Based Authentication and Authorization for Web Servers and Web API. There is also a Product Services Subsystem which integrates Authorization and user entitlements via an Online Billing System. Finally, at the highest level there are Business Extensions that are full functioning servers that provide Real-time and historical market data and Order Management services as well as other interesting services and systems I’ve created over the years.
Topics Core is open source and is organized into the following Nuget Packages:
Topics.Core – Centralized configuration, unified messaging API, Message Models, Interfaces and extensions used throughout the rest of Topics Platform.
Topics.Host – service hosting in either Windows Service or Windows Console Application
Topics.Messaging.InPocess – inter-process messaging via unified messaging api
Topics.Messaging.RabbitMQ – intra-process messaging over RabbitMQ
Topics.Messaging.SignalR – intra-process messaging over WebSockets using SignalR
Topics.Messaging.TibcoRV – intra-process messaging over TibcoRV
Topics.Web – Base level Authentication and Authorization interfaces and message models. SignalR Hub.
Topics.WPF – WPV MVVM via AvalonDock, multi-document interface.
Topics.Xmpp – Xmpp and chat room functionality via SharpXmpp and OpenFire Admin web api.
Presentation Services is also Open Source and is organized as a collection of Visual Studio “Tokenized” projects. What is a Visual Studio Tokenized project? Don’t worry; I just made up the term. It’s simply a Visual Studio project that has a tokenized name, workspace, csproj filename, etc, that allow for building and testing Web Sites and Web API servers based on Topics Core, but with different web framework or UI software stacks. Tokenized projects can then be used as a template to generate application servers, for example. The end result is a cookbook of sorts that allows one to construct new systems with tested software stacks. Applications generated from Tokenized projects come equipped with SDLC scripts for:
- Creating a Continuous Integration build system
- Integration to Source Control
- Automated Deployment
- Ability to create new environments
The Application and Product Services, as well as Business Extensions levels are available with flexible terms and optional support. To get more information, please go here for contact information.