Channels ▼
RSS

Security

Parameterized Communication

Source Code Accompanies This Article. Download It Now.


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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video