message translation/passing

Confused on how to handle - what I'll call message translation between
subject and a handful of listeners in my design. With the current
design, the subject transmits a ST1 message type to Listeners.

Upon receipt of the S1 message type, the listeners (depending on the
listener) will copy the parts of the S1 message type to - say LR3 and
LR4 messages types. LR3 and LR4 message types are types the listener
understands. There are two configuration of Listeners A and B
respectively. For A an ST1 message type maps to LR1 and LR2 message
types. For B an ST1 message type maps to LR3 and LR4 message types.

The premise is the same in the reverse direction. If listener I
transmits LT1 and L2 message types to the Subject. The Subject upon
receipt of LT1 and LT2 message types copies the contents to the
listener I data area of an RT message type. i.e

Subject (RT) Listener I Listener II
[ Listener I data ] <--(LT1,LT2)
[ Listener II data ] <---------------------(LT3,LT4)


The question: Given the nature of the problem would the bridge
pattern prove viable in this scenario? So instead of receiving an S1
type, the listeners holds a pointer to the bridge and it's the
listeners responsibility to garner the information from the bridge.
The same is true in the reverse direction. It is the responsibility
of the Subject to garner the information from the bridge then fill in
the appropriate area in an RT type.

Of course, I'm unsure if there's a way to do this with a decent
message translator class (seems like alot of generic programming which
will confuse me a little).

Help

Thanks

Responding to Forums_mp@hotmail.com...

> Confused on how to handle - what I'll call message translation between
> subject and a handful of listeners in my design. With the current
> design, the subject transmits a ST1 message type to Listeners.
>
> Upon receipt of the S1 message type, the listeners (depending on the
> listener) will copy the parts of the S1 message type to - say LR3 and
> LR4 messages types. LR3 and LR4 message types are types the listener
> understands. There are two configuration of Listeners A and B
> respectively. For A an ST1 message type maps to LR1 and LR2 message
> types. For B an ST1 message type maps to LR3 and LR4 message types.
>
> The premise is the same in the reverse direction. If listener I
> transmits LT1 and L2 message types to the Subject. The Subject upon
> receipt of LT1 and LT2 message types copies the contents to the
> listener I data area of an RT message type. i.e
>
> Subject (RT) Listener I Listener II
> [ Listener I data ] <--(LT1,LT2)
> [ Listener II data ] <---------------------(LT3,LT4)
>
>
> The question: Given the nature of the problem would the bridge
> pattern prove viable in this scenario? So instead of receiving an S1
> type, the listeners holds a pointer to the bridge and it's the
> listeners responsibility to garner the information from the bridge.
> The same is true in the reverse direction. It is the responsibility
> of the Subject to garner the information from the bridge then fill in
> the appropriate area in an RT type.

It depends. B-)

Almost all of the GoF patterns address the same basic problem. One has a
relationship among objects but the collaborations when navigating the
relationship require some sort of behavior substitution and that
substitution depends dynamically on context. IOW, the dynamic
substitution complexity is too complicated to describe with a simple
static association.

A pattern would be a good idea if the substitution was only known at run
time (e.g., different types of Listeners could be substituted based on
the state of the solution). The pattern allows you to dynamically
instantiate associations to the right participants for the
collaboration. A pattern *might* be a good idea if there are lots of
Listeners and Subjects and you need to organize them in a systematic
manner (i.e., using the same mechanism for matching them up).

However, as described so far there is only one flavor of Subject and two
flavors of Listener at all times. If so, I am not sure you need a
pattern at all because there isn't any *dynamic* substitution of behavior.

1 R1 sends S1 to *
[Subject] ----------------------[Listener]
A
| R2
+---------+--------+
| |
[TypeA] [TypeB]

Since Subject only sends one message, the Listener in hand knows what to
do with it. Now each flavor of Listener responds to Subject with a
different flavor of message, as in:
[Listener]
A
| R2
+-----------+------------+
| |
[TypeA] [TypeB]
| * | *
| |
| R3 | R4
| |
+------ [Subject] -------+
sends LT1,LT2 to 1 1 sends LT3,LT4 to

Subject needs to know if the message is LT1 or LT2 to parse it or
whether the message is LT3 or LT4 to parse it. So there has to be an
embedded message identifier in the message anyway. Then all Subject
needs is to parse *whatever* message it gets based on that embedded
message identifier. That's pretty straight forward and I don't see a
need for a pattern.

Even if there are different flavors of [Subject] to handle different LTn
messages, that is still fairly straight forward:

[Subject]
A
| R5
+--------------+------+-------+----------------+
| | | |
[DoesLT1] [DoesLT2] [DoesLT3] [DoesLT4]
| 1 | 1 | 1 | 1
| sends LT1 to | sends LT2 to | sends LT3 to | sends LT4 to
| | | |
+-------+ +------+ +------+ +-----+
R6 * | | * R7 R8 * | | * R9
[TypeA] [TypeB]
| |
+--------------+-----------------+
| R2
_
V[Listener]

So all you need to do here is instantiate the R6-R9 associations
properly. Then the Listener in hand will pick the right association to
navigate for the LTn format it is currently producing. That ensures the
right flavor of [Subject] will process it.



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

> Subject needs to know if the message is LT1 or LT2 to parse it or
> whether the message is LT3 or LT4 to parse it. So there has to be an
> embedded message identifier in the message anyway. Then all Subject
> needs is to parse *whatever* message it gets based on that embedded
> message identifier. That's pretty straight forward and I don't see a
> need for a pattern.

I think I agree with you on this. I've tried to clear up some errors/
omissions in my previous post. There's a Registrar is the middle.
As such would it make sense to do the message translation within the
Registrar? Currently the Registrar serves as a pass through.

Again take the case of a message transmission from

Subject to Listener via Registrar. Here the two Listeners (could be
one) get notified of an ST1 message type
from the Subject. From the ST1 message type each Listener builds
their appropriate LR message type.
----------------------------------------------------------------------------------------------------------------------------------
Subject Registrar Listeners
[ST1] --- [ pass through ] ---> Listener A builds
[ LR1]
[ LR2]
from the ST1

[ST1] --- [ pass through ] ---> Listener B builds
[ LR3 ]
[ LR4 ]
from the ST1


Message transmission from Listener to Subject via Registrar
----------------------------------------------------------------------------------------------------------------------------------
Listener Registrar Subject
A sends [1U] --- [ pass through ] ---> Subject builds
[ 2V ]

[ 13V ] (14V is specific to Listener A)
from the
1U

B sends [3U] --- [ pass through ] ---> Subject builds
[ 2V ]

[ 14V ] (14V is specific to Listener B)
from the
1U

Responding to Forums_mp...

> I think I agree with you on this. I've tried to clear up some errors/
> omissions in my previous post. There's a Registrar is the middle.
> As such would it make sense to do the message translation within the
> Registrar? Currently the Registrar serves as a pass through.

What's the semantics of the Registrar? Usually it is some variant of the
Observer pattern whose sole responsibility in the problem is to
re-direct announcement messages to objects that care about what
happened. So I would probably try to keep that responsibility pure...

>
> Again take the case of a message transmission from
>
> Subject to Listener via Registrar. Here the two Listeners (could be
> one) get notified of an ST1 message type
> from the Subject. From the ST1 message type each Listener builds
> their appropriate LR message type.
> ----------------------------------------------------------------------------------------------------------------------------------
> Subject Registrar Listeners
> [ST1] --- [ pass through ] ---> Listener A builds
> [ LR1]
> [ LR2]
> from the ST1
>
> [ST1] --- [ pass through ] ---> Listener B builds
> [ LR3 ]
> [ LR4 ]
> from the ST1

Note that ST1 is a pure message. It consists of {messageID, <data
packet>}. At the OOP level messageID may become a method signature
(e.g., processLT1Message(...)), but that interface method will have to
be in the ListenerX interface. IOW, no matter who formats ST1, ListenerX
needs to understand how to decode the <data packet> and build LRn from
it. So the Registrar pass-through is quite literally that; Registrar
should not need to understand the semantics of whatever is in <data
packet>. (An exception is when data embedded in the <data packet>
determines which Listener should get the message, but that's all
Registrar needs to understand.)

<aside>
BTW, I have been making a big assumption here that the real problem is
some sort of UNIX sendmail-like morass of a gazillion platform and
network protocol formats. Implicit in that is the assumption that
Listener's primary responsibility is formatter messages, as opposed to
doing something interesting with the data in the <data packet>.

If that is not the case and Listener has different problem space
responsibilities, then I would suggest delegating them.
Divide-and-conquer works very well in the OO world so it is usually a
good idea to separate concerns. Formatting and routing various messages
is a very different problem than doing something intelligent with the
message data, so I would try to isolate and encapsulate those concerns
in different objects. IOW, use a Listener object as a buffer between the
message formating and addressing concerns and the objects that are doing
something useful. So the Listener role would be analogous to the
Registrar role and someone else would actually process the data once it
was in a convenient format for them.
</aside>

>
>
> Message transmission from Listener to Subject via Registrar
> ----------------------------------------------------------------------------------------------------------------------------------
> Listener Registrar Subject
> A sends [1U] --- [ pass through ] ---> Subject builds
> [ 2V ]
>
> [ 13V ] (14V is specific to Listener A)
> from the
> 1U
>
> B sends [3U] --- [ pass through ] ---> Subject builds
> [ 2V ]
>
> [ 14V ] (14V is specific to Listener B)
> from the
> 1U

This is somewhat different because there is only one Subject listening
for multiple Listeners' messages. But the same logic applies. Registrar
doesn't need to understand the semantics of the messages; it just knows
which Subject to forward them to. Subject still needs to decode the
<data packet> and create the 2V and 13V or 14V formats.

[Note that conceptually this Registrar is quite different than the one
that routes ST1 messages. So you might want to validate that you really
need a Registrar mechanism is both directions.]

The tricky part is in knowing which input format for the <data packet>
to decode. But the messageID (1U vs. 3U) provides that. You could do
that will two Subject interface methods, say process1UMessage(...) and
process3UMessage. But that would require Registrar to know what
responsibility to invoke as well as what object to address.

That is a situation where I would be inclined to embed a secondary
messageID for 1 or 3 in the <data packet> for a single U message.
Listener still needs to know what it is formatting so it can encode the
message type code in the data packet. Subject still needs to decode the
<data packet> and it can look for the embedded code first.

But if the processing for 13V and 14V is complex (or there are other
problem issues) it might be convenient to subclass Subject and have
Registrar decide which subclass of Listener to invoke for 1U vs. 3U.
(IOW, Registrar is logically the one to <temporarily> instantiate the
association between Registrar and the right subclass object of Subject
to process the format in hand.) Then we would have the situation I
mentioned earlier where Registrar needs to have a limited understanding
of the <data packet>.

IOW, there is no one-size-fits-all design solution here. The choice will
depend on the specific problem space (e.g., what problem space rules
actually dictate what formats to use).



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH