Brandslang means “firehose” in Dutch.
Brandslang (not a name I like in the least) describes a non-enterprise service bus. That is it endeavors to integrate data everywhere except the enterprise. Many enterprises may choose to bring Brandslang data into their ESB, but the project itself does not endeavor to solve those needs. Instead, it leverages many of the same technologies often used to implement an ESB to enable ubiquitous data mashups.
The idea is that any entity can submit data into a Brandslang node and it then bears the potential to be consumed by any other participating entity. The entity could be a light switch as easily as it could be a unimaginably complex cloud-based neural network. The main premise is that data is fed into Brandslang, fed out to zero or more other entities within that Brandslang node or through a federated network of participating nodes. There are key underlying tenets of privacy and personal control of data which will be described later.
I have here a USB scale. On top of it I will rest a wireless RFID reader. In todays world, I would write some sort of program that would read input from both and do something interesting. Instead, each will simply feed events into a Brandslang node and then be correlated by my program. My program doesn’t need to know anything about the paticular scale, or the paticular RFID reader. My program is simply subscribing to Weight events and RFID_Read events.
When I put this water bottle on the scale, the RFID reader publishes the bottles tag id and the scale publishes a weight. My program puts these together and knows that at this time, the water bottle weighs 1.33kg. Big whoop. Except that next time I set my water bottle down, it knows that it weighs 1.23kg. Just by setting my water bottle down on this huge, fancy coaster I now know that I just drank 10ml of water. And so long as I keep putting the bottle down on this coaster, I’ll know the rate at which I consume water. In fact, if I have one of these scale/RFID reader setups at home, there isn’t any reason why these events can’t be picked up through my personal federated network of Brandslang nodes. I’ll leave it to someone else to simply incorporate the scale into the water bottle.
My code doesn’t need to know that there are two different scales, or that they’re in two different places. However, since location is powerful, Brandslang understands it at an underlying tenet of every event. So my program can be made to understand my consumption rate at home vs at work, again without modification of the scale, reader or the “drivers” for those devices.
Lets make this a little more interesting. Here’s an RFID tagged bowl. I set it on the scale, and since one of the properties of this bowl is it’s empty weight, the scale can automatically tare itself. Okay, now half a cup of flower goes into the bowl. A new weight event is fired off, but this time I have no idea what’s been put into that bowl. Except, that I’m working with a recipe that calls for half a cup of flour. These can be put together and through the magic of heuristics we can have a pretty good guess at what it is. Brandslang isn’t doing anything special here except giving the scale, a recipe management app, some possibly separate heuristic analysis app an opportunity to all work together.
Brandslang isn’t just about these complex use cases involving real-time cooperative data exchange between discrete components either. It presents opportunities for plain ol’ data transport as well. If I want to get my music player to tweet the media I’m playing, or perhaps just when I’ve rated a particular media highly it should be fairly straight forward. The music player or an “adapter” would need to feed data about what media was playing and/or ratings as I rate that media to Brandslang. A simple, universal twitter adapter could subscribe to that data and publish it to my twitter feed. A Facebook adapter could be doing the same. Simultaneously. And so on and so forth until every esoteric status publishing webapp du jour is letting the world know I love to watch “Blazing Saddles”. The key here is that the media player app doesn’t have to support each and every one of those status publishing apps, they only have to feed that data once to a Brandslang node. The user then can decide how that data gets filtered and where it gets sent off to.
Let us explore one of my favorite user stories today. I use a handful of iPhone/web/desktop apps to enter data about what’s going on in my life. Each of these apps puts the resulting data into it’s own proprietary data store. None of them meet all of my needs and only a rare few are open enough to give me the opportunity to pull the data they contain into some sort of personal data warehouse. Some, (like my FitBit) combine manually entered data with data collected automatically from sensors. Now, I don’t expect that any of these solutions will be able to meet all of my needs, and particularly not soon. What they each can do is offer me a feed of _my own data_ so that I can do with it what I will. Implemented as a retrofit, either a Brandslang adapter can be written against a more common API or it can be implemented as a Brandslang batch/real time publisher feeding my data back to me. Fully incorporating Brandslang into the stack is optimal. Instead of my data capture apps or sensors sending the data ‘out of band’ back to the proprietary data store in the first place, have it feed into my personal Brandslang node. According to my personal preferences around attributes such as privacy I can then forward it along to that proprietary data store while also sending it to some local application, a device or even an additional proprietary data store. My hope is that someone will see the opportunity and jump into this personal data warehouse/analytics space lickety-split.
I’ll be the first to point out that this clashes with more than a few business models. However, I look at it from a different angle. If you have a data-oriented business model, leveraging Brandslang increases the opportunity to get data from sources you don’t have to pay to develop. It also increases the opportunity for your users to feed that valuable data to someone else, including a competitor. So compete! Give your users a reason to feed data to you. Give them value in return! If you have a data capture oriented business model (developing tools/sensors), then leveraging Brandslang gives you a competitive advantage since you can feed your data to any other participating entity.
The promise of Brandslang is universal integration that has privacy and security built in and is easy enough for common users to configure. It’s a very tall order, but using commonly available, open source tools, it can be accomplished.
Tech Details Super-Alpha-Preview.
That’s right, not even slideware, this is asciiWare.
- Apache ActiveMQ (basic transport)
It’s uber-flexible in terms of deployment. It can be embedded into an existing JVM or J2EE stack and theoretically can scale “to infinity and beyond”
- Apache Camel (additional adapters, transformation, aggregation(?), etc)
Plays nice with ActiveMQ
- Esper (Not sure if CEP fits into the Brandslang mission, or if it’s an extension)