Karate MockServer enhancement to support non http protocols like JMS, GRPC, GraphQL or any other custom protocol

[naveenchandra91]

Firstly kudos for Karate library to develop a fantastic Over the wire test double mocking which is unparalleled in terms of capabilities. Its simple and straightforward and I was able to mock the http service downstream in a matter of hours!

Similarly we have downstream services which are of different protocols like JMS. I would want the ability for karate to listen to JMS server and intercept the call and forward/mock the api call and return response. Currently I dont think it is supported. But It should be possible with some changes to MockServer and other enhancements.(Would love to raise a PR for this).

I can think of the following changes to support this enhancement(I might be wrong, please suggest other ideas/improvements):

1. Modify MockServer extends HttpServer and add a Strategy pattern based support
   to add multiple protocols implementation like JMS, GRPC, GraphQL or any custom protocol(User can pass the java interop during runtime to establish how he wants the connection or protocol to be handled)
2. Modify MockServer builder to add methods for protocol like JMS, GRPC, GraphQL or Custom Protocol(Karate acts like a SocketServer, rest of the protocol details provided by user via Java Interop)
3. Dont spin up a HttpServer if http builder method is not called. Instead use a port method for Karate to listen to connection requests. And let the user decide the connection protocol should be.
4. Ensure http connections works as is currently if http builder method is called.
5. Enhance karate.proceed proxying for other protocols. We can enhance proceed function to take custom java interop function to let user decide how proxying should happen.
6. Add more generic convenience functions like pathMatches for other protocols so that karate can intercept the server requests for proxying or mocking the response.

[ptrthomas]

@naveenchandra91 thanks for the kind comments. as you can imagine it is hard to generalize mocks, so one point of view is that teams can build their own with little effort following the example here: https://x.com/getkarate/status/1417023536082812935

the other point is that we have commercial extensions for async protocols now, and mocks may eventually be part of that - but we don't see a critical mass of teams needing it