Home

• explain
• command-line
• schemas
  • b: ms: base
  • c: msc: concept
• contact

Explain

• Compare
• Base
• Concept

Implementation:

• Messages
• Formats

Infrastructure:

• Components
• Network

Explain Network Dynamics

"Classis" application networks focus on stability: Development hands over a new version of the software to Operations, which then maintains the application until the next version arrives. Typical environments contain alpha, beta, acceptance, and production set-ups to reduce the chance that bugs or misfeatures arrive at the system where the real data is.

This set-up has a number of disadvantages:

• It can take very long before a bug-fix or feature gets into production.
• Users of the application need to synchronize their upgrades with the change of production versions. We try to fight this with requiring backwards compatibility;
• Test-versions require resources which mimic the real environment to be able to do realistic tests.

Knowing that there are many approaches, like A-B testing and CI (Continuous integration) to make this process faster, these all stick to the concept that one choice is leading. (Although tempting, for the matter of this page, let us not discuss all strategies in detail here.)

Meshy Space offers a way to get rit of these versions with specific roles. You can still implement the models you know, but it provides a more generic approach.

Dynamic Operations

Meshy Space provides "units", which are objects with life-cycle management. These "units" are grouped into "collections". This is not only used for data, but also for interface descriptions. A unit can be (in SOAP terminology) an operation, and a collection of operations is a service description.

Standard Meshy Space management features allow you to add or deprecate published operations at any time. This way, you implement a sliding interface specification. The speed of CI, but without dropping the old version when there are still users of it. Users can get a window of time to adapt to interface changes.

Dynamic Services

The (collection of the) service description not only contains (units which manage) operations, but also (units which manage) end-points: access descriptions of physical servers.

Standard Meshy Space Concept collection management features (filters) will enable the developers to restrict groups of users to see different sub-sets of interface. Both operations and end-points.

An example

We are going to update an existing operation with a new constant error-code, which may be returned by the server. Such a minor change may break automatic processing at the users side, even though changes are slim. We publish a new unit to our collection, a new operation version into our service description.

When the previous operation version had name "get-v1234", the new unit gets name "get-v1235". The new operation can only be accessed (via collection rules) by users in group "test". The application supports both versions of the operation at the same time.

When the testers are happy, they open access to the new version for everyone. The older unit gets an update: it refers to a logic follow-up. Some users may trigger on that change and check whether they can upgrade safely as well. But there is no real need: the user can always wait for his normal upgrade process.

After some time, the developers decide they need to clean-up the old interface. The (life-cycle of the unit which defines the) operation is set to state deprecated. Maybe even an expiration time is provided. Now, the service users which still use the that old operation implementation will get informed automatically: they must to upgrade as soon as possible. When the expiration time is reached, the operation (unit) is removed everywhere automatically.

The same procedure is used to change the end-point units and the collection configuration changes, like access rules.

Conclusion

At any moment of time, the service description has a well described state. For every user, it is well-defined what they can see and do. At the same time, that state moves: the service publishes changes and the user gets time to adapt to those changes.

It is important to understand that the features which are required to implement dynamic operations and dynamic services are exactly the same as which is used to maintain any data collection.