Make transportmessages:Can serializer (de-)serialize objects?

Sep 12, 2011 at 1:24 AM
Edited Sep 12, 2011 at 1:26 AM

Hi !

In my scenario, imagine, I have - in minimum - four hops between agents:

A(requestor) <-> B(coordinator) <-> C(distributor) <-> D(worker) [<-> E(subworker)]

Messages created to be processed on D/E have to be passed between all agents
in the chain. B is not interested in all content, but creates routing information
and then create - or change - the/or new messages to (all) C. These message now have
just a changed "header", but the most parts are unchanged. So the main part of the
chain does not need to know about content details, but must just be able to send
them. Additionally, the way back is probably another route.

In this scenario, would the following code [symbolic]:

public class MsgContract : PortSet<MsgContract.MsgEnvelop>
{

  [serializable]
  public class MsgEnvelop
  {
      public Guid Id;
      public RouteInfo RouteInfo;
      public Type Type;
      public object Content;
   }
}

this be (de-)serializable? I would have to make something like a dispatcher
at the end of the chain [in D above]. The problem there [D] is, that an
additional E could be present. So I cannot properly determine the end
of the chain statically. If this would be fixed, C would just unpack the
message and send the "rest" to D.

Any ideas could really help me! Note: This is a bit related to my question
titled: "How to organize code for "bigger spaces", because it would drastically
reduce the number of contract messages.

Thanks so far and
best regards,

++mabra

Sep 12, 2011 at 11:36 AM

Hi mabra,

Yes there shouldn't be any problems with the serialization of object fields, as long as the contained object is serializable. The appspace itself internally uses a similar message structure as in your example, since the user could of course post any possible kind of object.

As for the non-static length of the chain, I fear that I don't exactly understand the problem - could you explain in more detail?

Best regards
Thomas

Sep 15, 2011 at 10:50 PM

Hello Thomass !

Thanks a lot, for your response, this makes clear, what I have hoped !

I am just not sure at the moment, what I am excactly telling you about the relationship between D+E ;-)

From my experience, I will prevent me to install agents on just every machine ... I learned that in my company with
IBM director agents ... We had that blue eyes, to install them on one rush onto all servers and it immidiately made
headache on most of them. D is more a pet, while E is a specialist. If you want to do things like process tracking,
you should really not start that remotely and decide there, what to do. In this case, an admin - or remote install
task - should bring in place E, which connects to D. In this case, D is no more pet only, but router for E. The second
reason is, that I am currently not a remote-installation expert ;-)

Thanks and
best regards,

++mabra

Sep 16, 2011 at 10:00 AM

Hi mabra,

I still don't know if I understand the D+E connection correctly, but if E is only optional, you could just let E register with a remote port at D, and D acts accordingly to the fact if there is an E registered or not. Or you could of course also run a lookup service and let D make a lookup from time to time, if there is an E available.

Best regards
Thomas

Sep 16, 2011 at 10:46 AM

Hi Thomas !

Yes, this is excactly, what I do [the first option]. What I was saying is, that the message-chain is not fixed.
Initially, I thought have a fixed endpoint would help me to put this into the message and have identical
behavior on route and at endpoint.

I have not much currently, I stuck - for other reasons [like time ;-) ], between A and C ;-)
and leran more about such an infrastructure could and should like.

br++mabra