Support publish-subscribe message queue or rather more like publish and push notification mocking?

[David Luu]

I'm just starting to look at mountebank. If I'm not mistaken, it's a configurable mock for request & response type protocols? so far being HTTP and TCP, with the reconfiguration part done over HTTP (setup & teardown imposters, reconfigure imposters).

So naturally, a publish-subscribe message queue workflow could be adapted to be mocked with mountebank (whether or not a mock server is used in mountebank or we relay through an actual message queue server with mountebank imposters subscribing and publishing to the message queue as clients). In this setup, the subscriber imposter getting a message equates to receiving HTTP requests, and publisher imposter publishes a mocked response like a mocked HTTP response. Supposedly we would have 2 imposters to simulate request-response or publish-subscribe mocked flow. Subscriber is to one queue/topic and publisher is to another.

But what about case of publish only or push notification flow? Where we don't mock a response based on input received but want to arbitrarily inject/trigger an event that publishes a message to the queue or sends a push notification to the other party that is subscribing to such. Is there a mechanism in mountebank for this or could it be easily extended for this? For example, a special HTTP call to mountebank to tell an imposter to do something (publish message, send push notification), where normally that imposter does nothing if not triggered by such a call. This type of imposter could be TCP or some other custom protocol/implementation.

FYI, I was just thinking of this in terms of another discussion about Apache kafka support: https://groups.google.com/forum/#!topic/mountebank-discuss/l_TbvZCkjh4. Was thinking for that, we wrap a kafka client (publisher & subscriber) into a custom single imposter on mountebank (on receive subscribe message on queue A, publish a mocked message to queue B). But I have use case for a publish only model as well. And then it would be interesting to see how mountebank could be used for push notification workflows as well, although I've not dealt with that type of thing yet other than publish-only case to a queue.

Any thoughts or tips on this discussion?

[Brandon Byars]

Hi David,

Answers inline:

On Thu, Dec 17, 2015 at 12:14 PM, David Luu <mang...@gmail.com> wrote:

I'm just starting to look at mountebank. If I'm not mistaken, it's a configurable mock for request & response type protocols? so far being HTTP and TCP, with the reconfiguration part done over HTTP (setup & teardown imposters, reconfigure imposters).

Yes.

 

So naturally, a publish-subscribe message queue workflow could be adapted to be mocked with mountebank (whether or not a mock server is used in mountebank or we relay through an actual message queue server with mountebank imposters subscribing and publishing to the message queue as clients). In this setup, the subscriber imposter getting a message equates to receiving HTTP requests, and publisher imposter publishes a mocked response like a mocked HTTP response. Supposedly we would have 2 imposters to simulate request-response or publish-subscribe mocked flow. Subscriber is to one queue/topic and publisher is to another.

But what about case of publish only or push notification flow? Where we don't mock a response based on input received but want to arbitrarily inject/trigger an event that publishes a message to the queue or sends a push notification to the other party that is subscribing to such. Is there a mechanism in mountebank for this or could it be easily extended for this? For example, a special HTTP call to mountebank to tell an imposter to do something (publish message, send push notification), where normally that imposter does nothing if not triggered by such a call. This type of imposter could be TCP or some other custom protocol/implementation.

Right now mountebank only sends responses triggered by a request, but it's certainly conceivable that it can trigger a server side response independently.  I'm planning on doing this for webhooks soon.

 

FYI, I was just thinking of this in terms of another discussion about Apache kafka support: https://groups.google.com/forum/#!topic/mountebank-discuss/l_TbvZCkjh4. Was thinking for that, we wrap a kafka client (publisher & subscriber) into a custom single imposter on mountebank (on receive subscribe message on queue A, publish a mocked message to queue B). But I have use case for a publish only model as well. And then it would be interesting to see how mountebank could be used for push notification workflows as well, although I've not dealt with that type of thing yet other than publish-only case to a queue.

Any thoughts or tips on this discussion?

I think the trick with kafka isn't building the client - for which there are already node implementations - but building the kafka server.  You'd need an imposter listening that acts as the core kafka infrastructure, and I didn't see any node implementations out there that would facilitate that, meaning it'd require writing it from scratch.

-Brandon

[David Luu]

I got your point about mocking kafka server and no node implementations available. I was thinking in the interim, for a publish + subscribe workflow, it may be easier for us to wrap an imposter implementation around a node kafka client that routes data through an actual kafka server. The imposter is both a kafka subscriber and publisher. On impostor receiving a kafka subscription message, it would then publish back out a mocked response to kafka (usually to a different queue/topic than the subscribed one). Would doing this rather than an imposter that directly listens on a TCP port(s) require defining a new protocol for mountebank to differentiate the impostor implementation (to pick the right one)?

[Brandon Byars]

Ah, I see now.  Yes that could work.  We could implement proxy-only capability by using existing client implementations.  You should be able to do this in tcp, but it can be really difficult if the packets are large because a generic tcp protocol has no way of knowing when a logical request is complete unless you give it some protocol-specific information in an endOfRequestResolver.

--

You received this message because you are subscribed to the Google Groups "mountebank-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mountebank-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[chinni]

I would like to understand this portion of the discussion.

--------------------------------------------

> So naturally, a publish-subscribe message queue workflow could be adapted to be mocked with mountebank (whether or not a mock server is used in mountebank or we relay through an actual message queue server with mountebank imposters subscribing and publishing to the message queue as clients). In this setup, the subscriber imposter getting a message equates to receiving HTTP requests, and publisher imposter publishes a mocked response like a mocked HTTP response. Supposedly we would have 2 imposters to simulate request-response or publish-subscribe mocked flow. Subscriber is to one queue/topic and publisher is to another.

---------------------------------------------
I have a requirement for the below described situation.
We have rest services which are calling external service - passing request (soap message) to MQ Request Queue and get the response into MQ Response Queue which is read back and routed to rest service. I need this back-end service calls captured and made as virtual server.Is this even possible with mountebank as there is no MQ support at this time.
with tcp protocol, proxy setup did any one get this working before?
Thanks