Parameterized Communication
Imagine your application connects to a server with the intent of using some service. Using Obol, the server can say, "Oh, you have to use this protocol to use that service!" The client application can then retrieve and inspect the protocol script, and if acceptable, run it.
This approach can also be turned around, so that the client says "I can only run these protocols!" The server can then examine the client's protocols, and run those that it judges to be compatible or adequate.
It might also be possible to negotiate and synthesize a script that is satisfactory to all participants, although protocol synthesis is believed to be very difficult, due to semantic consolidation over contextual borders.
Notice that even if your client application now knows which protocol to follow to access the service, use of the service itself must be dealt with by other means; for example, using Jini for driver distribution, running on top of a protocol initiated by means of Obol.
When the way communication is done has been decoupled from use of that communication, you can do all kinds of interesting things.
By embedding scripts in certificates, you gain two things:
- You can exploit the associated features of the certification infrastructure to revoke and distribute protocols.
- A statement of intent—if scripts for all participants are included in a certificate, conformity to the protocol is directly verifiable.
It's possible to change a protocol while it is running. Obol can do this by copying one script's local state into another instance's state. In this case, care must be taken to ensure that the two scripts are sufficiently compatible, to make the change-over decently predictable. Exactly how to determine, mechanically, if two scripts are compatible enough turned out to be harder than we thought. We're unsure of how to make this feature safe enough to be useful, so it's disabled in all current Obol versions.
One problem is that applications that don't know about Obol can't fully participate. Obol has been constructed so that message representation during transport has no side-effects in the language proper, meaning that it's nice if both sides utilize Obol, but it's not required. As long as the Obol environment can parse and represent messages in a way that's understood by the peer, the protocol can progress, although the Obol side is limited to striving for compatibility with the peer. Unfortunately, although the message representation machinery is modular, representation formats cannot yet be encoded in the Obol language, but must be provided as Java classes.
There is also another problem, which Obol shares with middleware in general—what to do after all the reflection and inspection has been done. It's possible to enter the state where the protocol has been negotiated and executed successfully, but the application has no clue what to do with the result.
