Archived

This forum has been archived. Please start a new discussion on GitHub.

IceStorm and dynamic invocation

rsanhuez
edited December 2017 in Help Center

Can I use IceStorm with dynamic invocation for decoupling publishers and subscribers even further?

Tagged:

Comments

  • benoit
    benoit Rennes, France

    Hi,

    Yes, using dynamic invocation is possible with IceStorm and also Glacier2. Dynamic invocation is really just a local API that allows to receive or send an Ice invocation as a byte sequence "blob".

    Cheers,
    Benoit.

  • rsanhuez
    edited January 2018

    Just for clarifying,

    IceStorm with static invocation requires a topic interface (SLICE) which will then be implemented by the subscribers. A topic is essentially equivalent to an application-defined Slice interface: the operations of the interface define the types of messages supported by the topic.

    Does this mean that IceStorm with dynamic invocation can send blobs without using SLICE (which would bind the publishers and subscribers at development time)?

  • benoit
    benoit Rennes, France

    Hi,

    This would be an unusual use of IceStorm and the Ice Blobject API but yes: you can send a blob which doesn't necessarily follow the Ice encoding of a Slice operation defined in Slice. The sender and the receiver just need to agree on the encoding of the blob.

    Cheers,
    Benoit.

  • Dear Benoit,

    I think I formulated bad the question. It is okay to use SLICE for encoding the messages. The question really should be: Do the consumers of the message (subscribers) require to know the SLICE definitions at development time or they can discover them at runtime so they can decode the events?.

    The same question applies to the classic two way dynamic invocation. Can I write a generic client that discover the server SLICE interface at runtime?

    I ask these questions because if I can send blobs, but the publisher and subscribers (or client and server in the dynamic invocation) should agree in the format of the message beforehand they are still binding at development time which is not desirable for dynamic communication.

    I hope you can clarify this to me and I really thank you for your time

    Renato

  • benoit
    benoit Rennes, France

    Hi Renato,

    The Slice translators in the various language mappings don't generate metadata information for the Slice operations declared with a Slice interface. So there's no easy way for a client or server to discover how to decode the parameters of an operation at runtime. In some language mappings, such as Java or C# for example, you could use the reflection API to guess the type of the parameters to decode but this won't work with all the languages.

    Generating metadata information for the Slice types is something we considered adding in the past but since we never really had any customer demand for it, we didn't add it. I believe the use cases where such information is needed are also quite limited (protocol analysers, ...). Do you have a specific use case in mind where this would be useful?

    Cheers,
    Benoit.

  • rsanhuez
    edited February 2018

    Hi Benoit,

    I also believe that the use cases for dynamic communication are limited due its complexity. An specific use case can be any case in which a generic client can be useful. For me it is just a matter of flexibility. Having the opportunity to use dynamic invocation if I need it or just use static invocation for easy software development.

    I have to say that the terminology confused me because, if I understand correctly, Ice can only provides dynamic invocation for language bindings that support reflection. Without a way of discovering server interfaces at runtime, the client and server should make an agreement at development time which is basically static invocation (without the type check).

    A similar situation occurs with Message Oriented Middleware (MOM). If MOM use XML as serialization format then the communication can be dynamic because it uses a self description language that can be understood at runtime. If MOM uses non-self-describing messages then the clients and servers (or peers) have to make an agreement at development time about the message format.

    This has being a very useful conversation for me. I hope to hear your thoughts, maybe I missed something.

    Renato

  • benoit
    benoit Rennes, France

    Hi Renato,

    That's correct, Ice supports dynamic invocation for most language mappings with the Ice streaming API and the Ice dynamic invocation API but it indeed doesn't provide an API that provides metadata information on the Slice interface implemented by a server and which would allow a client to perform the encoding of the invocation with no extra knowledge.

    What are the client applications that don't have any knowledge at all of the server interface but still need to perform invocation on it? I don't think there are many...

    In general, a client always have some sort of knowledge on the service provided by a server. A client might not include the generated code that provides static typing for the interfaces however which is there Ice dynamic invocation can be useful.

    Cheers,
    Benoit.