How to model duplex asynch services

[William McKenzie]

I'm working on a protocol that involves the exchange of messages over web sockets. The communication is bi-directional and asynchronous. There are two distinct roles (i.e. consumer and producer), and there is a subset of the messages that are allowed for each role. Essentially consumer asks for data and producer sends it. But it's asynchronous and message-based instead of RPC style.

So at each end of the communication, there will be something that looks like a bunch of calls - SendXxxx(message) when you send messages - and a bunch of events - <<signal>>OnXxxx(message) for when you receive.

Is it best model this as one interface and simply make it required of one role and provided by the other, or would it be better to make IProducer and IConsumer  where each is the opposite of the other (i.e. signals become calls and vice versa).

Is there any real advantage to doing it one way or the other?

[qwerty]

If you want to create code for the interfaces the IProd/ICons variant is better. If you just want to visualize the message exchange the simple message are easier to create.

q.

[William McKenzie]

Thanks, that seems reasonable. We're actually trying to publish this as a specification, so I think probably the 2 interface definition makes more sense.

Supplemental question: I'm thinking the events are specified as methods with a stereotype of <<signal>>. Is that how you would normally do an event on an interface?

[qwerty]

Stereotyping from my POV is a matter of taste. But yes, I would also choose <<signal>> in that case. Makes perfect sense.

q.