The ActingWeb logo (above) shows lots of dots connected to each other. Visually, this is actually what ActingWeb looks like on the Internet. Tiny applications talk to each other to make things happen on behalf of a user. It’s your own personal friendly botnet!
However, the user does not have to see this. The user does not even need to know that what happens is accomplished by many small applications talking to each other and not one big application.
An ActingWeb application is called a “mini-application”. A mini-application has built-in ActingWeb functionality (typically as a library), so that it can connect to and communicate with other ActingWeb applications in a standardized way.
The second part of the application is the app-specific functionality. This component defines the data exposed to other mini-applications, the other mini-applications to connect to, and communicates with the thing or 3rd party service that this ActingWeb mini-applications represents.
On the right, you see a mini-application that controls a door lock. The door lock needs to have access to the Internet (at least once in a while). ActingWeb has a simple way the lock itself can connect regularly and post its status or retrieve new commands like unlock/lock (using http GET and POST/PUT requests).
The door lock app decides what and how to expose the lock to other mini-applications. E.g. the lock status can be exposed as a property at http://my-lock-app/<id-of-my-lock>/properties/lock. An http GET to this URL can return True if the door is unlocked and an http PUT with False as the content can lock the door (and the reverse).
As you see from the URL, <id-of-my-lock> is a part of the URL. This is a central part of what makes ActingWeb apps different. The application that implements the door lock does NOT handle thousands of other door locks. The mini-application can in fact ONLY handle one door lock and does not know anything about other door locks. That is why the id of the door lock is embedded in the URL.
Hence, the door lock mini-application is in reality many, many independent applications running in parallel, with no awareness of each other. They are doing the same thing, but each for “their” door lock. This is contrary to the way applications are most often made. Applications typically don’t only do something for one entity, like a lock, but also lots of other functionality, like answering questions like “is the software on all the door locks updated to the latest version?” And even if the applications are made to do just one simple thing for one entity, they are typically designed as multi-entity applications even if it’s not needed.
Why is this specialization such a benefit? One big reason is security. You can compare it to server or container virtualization: although running on the same physical server, everything is built from the ground up to be separated, so you can run two virtual servers or applications in containers alongside each other without worrying about what is going on in the other server or container. Another important reason is simplicity. If an application only needs to know about one entity of something, it doesn’t have to have lots of complex code to handle many of this something.
This is an extreme form of virtualization that can be called “microservice virtualization“. The microservice itself is de facto separated into one microservice per entity (like a door lock), not only one application per container.
Sidenote: the microservice virtualization approach does not lend itself to analysis across many entities of the same type. It is possible, but the approach would then be to build a more classic application that queries all the instances of the ActingWeb mini-application to build aggregated views.
Another key element of the ActingWeb is that the communication protocol, which also includes trust and security, makes it very easy to use functionality or data from another ActingWeb mini-application. The figure below illustrates this.
Above, you can see four different mini-applications, but only the instances that are connected to each other for one specific person’s home and location are shown (thus, for each of these four, there will be a “stack” of mini-app instances doing the same thing for other homes and people). In ActingWeb, an instance of a mini-application is called an “actor“. Thus, there are four actors above, each implementing their own narrow mini-application functionality:
- The actor controlling the door lock into our user’s home. Let’s call our user Tom
- The actor controlling the lights in Tom’s house
- The actor that keeps Tom’s location (posted from Google Location, a phone app, or any other source)
- An actor that trigger actions on specific times (configured by Tom)
As you can see, the door lock, lights, and timer actors are connected to each other. This relationship is part of the ActingWeb and is called a “trust relationship“. The trust relationship is established in a secure way, and each relationship has a security token that is used to secure the communications between the actors. Note that the relationship is between Tom’s door actor and Tom’s timer trigger, not between the generic door lock mini-application and the generic timer trigger application!
Each of the mini-applications have defined what kind of functionality is exposed to other actor’s. Not all relationships are equal, you want to control tightly who can see whether your door is unlocked, as well who can unlock it, and maybe you want to allow some trusted actors to know your location, but others can actually update it. Differentiating access is done through the type of the relationship.
There are four pre-defined types in ActingWeb (associate, friend, partner, and admin), with associate typically only having read access (above the lights actor can read Tom’s location), friends are allowed to do specific changes (above the door lock and timer actors can turn on the lights), and the partner is trusted to do more important things like locking and unlocking the door.
This more in-depth introduction should be enough to get a feel for what ActingWeb is. If you still feel it is a bit fuzzy exactly what ActingWeb is technically, it defines the following technically:
- A programming model, “microservice virtualization“, that allows tiny pieces of functionality for one specific user or thing to be exposed on the Internet as ActingWeb actors
- A distributed programming model that connects each of these ActingWeb actors into an intelligent network of apps (a “botnet“)
- A protocol that defines a set of REST-based endpoints and flows to establish trust relationships (/trust) and create subscriptions (/subscriptions) that send notifications (/callbacks) between actors on changes and events
- A set of REST-endpoints to expose application-specific data (/properties), actions, and other resources while automatically getting access to the trust relationships and subscriptions in ActingWeb
The above diagram shows the main REST endpoints exposed by an ActingWeb actor. Not all are mandatory, and there are a few additional available to manage sessions and RPC methods.
If you still feel you need more detail, the ActingWeb specification is where you want to go next. Or, if you want to see working code, you want to look at the reference library that is a (trivial, but extendable) ActingWeb mini-application on its own.
RSS - Posts