In the past my team has often used SoapUi to create automated tests around our SOAP webservice. Now we would like to create automated tests around our app's JMS communication. Therefore, we need to configure SoapUi to publish to and consume from our JMS queues.
The SoapUi website explains how to publish SOAP messages to a JMS queue. But this does not fit my usecase; my app sends arbitrary text messages over JMS without conforming to a SOAP contract.
Is SoapUi able to publish arbitrary text messages to a JMS queue, or must my messages conform to a SOAP contract defined by a wsdl? How would I configure SoapUi to publish these messages without it creating a dummy SOAP interface for the JMS connection to reside in?
The free version of SoapUi is intended to use test SOAP and REST. As the above link shows, SoapUi can be configured - through its GUI - to send messages over JMS only when these messages conform to a SOAP contract. However, SoapUi is also able to execute Groovy scripts, and these Groovy scripts can publish arbitrary messages to JMS. With the help of my team, I wrote a Groovy script which imports a Java library and uses this to publish arbitrary JMS messages.
Related
I have inherited an application at my job that is being converted from WCF to SignalR. It is a windows service created using Topshelf. When the service is started is connects to a SignalR hub. Various things may happen, such as a user sending a request to my service through the hub. Then my service will send back a request for their PIN. They send that back and my service then requests if they have authority to do their original request from yet another client. All of these various requests are interfaced of course.
Previously this was all done with WCF and we had a very comprehensive suite of tests for the service. Now that I am trying to switch all the tests over to SignalR I have no idea really where to even begin. Running any test starts the topshelf service as expected, but then of course it tries to connect to the hub which doesn't exist.
I have tried using Moq to simulate the hub, but it doesn't seem to work as mocking a running hub so of course I cannot get my service to connect to a mocked hub while the test is running. I'm not sure if that is a Moq limitation, or just me not understanding how to use it. I have also tried entirely recreating the hub as another project in the same solution as my service and testing project, but again I can't figure out how to actually make the hub run properly so that my service can connect to it when the test is running. Again, I assume that is my lack of knowledge. Our SignalR hub is created using the basic OwinStartup/MapSignalR process (just as in the microsoft chat app tutorial).
I feel like I'm going in a bunch of different directions and not getting anywhere because I don't know enough about SignalR and how to test it. I have done the basic "chat app" tutorial and the related tutorial about testing that with Moq, but once I try to add in the additional complexities of my project I just get lost.
What is need is for a test to run, "connect" to the SignalR hub, and give me a way to simulate the user request, and the user sending back their PIN, and the other client that sends back the authorization granted/denied message. All of the tutorials I find are for testing one single back and forth in that chain. I hope this all makes sense and someone can point me in the right direction of what I need to do to proceed. Thank you!
I have tried to recreate a hub within my project purely for testing, and I have tried setting up a Moq'd hub to connect to. I am expecting (hoping) to get a SignalR hub (real or mocked) that my service can connect to and do all of the various back-and-forths it needs to to test whatever it may be I am testing, for example the entire path of a user requesting to do something that they then have to authenticate with a PIN to do. So, not testing one method of the hub but a whole end-to-end process.
What is the basic difference between dispatching an Event by Messenger and dispatching an Event by Symfony EventDispatcher Component ?
Symfony Messenger is a tool to help you building a bus messenger system.
Typically, you would use it if your application needs to communicate with external services (using an AMQP protocol, for example).
The EventDispatcher system gives your components the ability to communicate between them.
You'll use this system if you want to make inner parts of your application communicate.
As you've already tagged this question with RabbitMQ: have you tried to use the EventDispatcher and RabbitMQ? I don't think this is possible.
But to cite the official documentation, located at https://symfony.com/doc/current/components/messenger.html:
The Messenger component helps applications send and receive messages to/from other applications or via message queues.
The pure ability to handle a message in another request (through using a transport) makes a huge difference to the EventDispatcher, which handles all given events in the same instance of your application. Restarting the application (through a new shell call, or a new web server request) will definitely kill all events that have not been handled yet through the EventDispatcher, but those stored using a transport might still be there
We plan to have a REST API exposed by Apigee Edge. The client-facing endpoints will be managed by Apigee. Another REST service will be hosted behind the Apigee. When the Apigee endpoint is invoked, we plan to store the request in Kafka so that it can be processed asynchronously. After the server has processed it, we intend to Push a message to the client application that made the request.
Is this a common practice?
Does Apigee have a feature to remember the client such as its websocket so that the notification can be pushed?
First and foremost, Apigee is a Gateway for synchroneous APIs. There is no default way to do "come back" to a request that has been processed earlier. So: No, this is not common practice.
A more common practice would be to add an asynchroneous callout to "another REST service behind Apigee", meaning that Apigee returns a response immediately without waiting for the target to complete. That backend service would then implement the callback on its own, possibly via some other Apigee proxy.
In your specific case, the pattern you're implementing is basically a message queue, utilizing Kafka as the message broker. In such patterns, it's best practice to have the message receiver send a reply message as soon as it finished its work.
Regarding websockets, Apigee doesn't support it at the moment (see https://community.apigee.com/questions/60513/apigee-as-websocket-proxy.html).
I am developing a mobile application using Telerik Platform. The services consumed by the app are ASP.NET Web API RESTful services which are hosted on Azure. I'd like to build some resilience into the app by adding a service bus and have been looking at Azure Service Bus which seems to be what I'm looking for.
It's fairly new to me and I have a few questions.
Can Azure Service Bus be used for RESTful services that return data or are they fire-and-forget only?
For simple RESTful services is Azure Service Bus the way to go or Azure Storage Queue? When would you use one vs the other?
When would I use a Queue vs Topic / Subscription?
ASB is about messaging. You use messaging for communication between parts of your system/services. RESTful services can leverage ASB by translating a request into a message to perform some work. Emphasis on converting the intent into a message, to instruct about work that needs to take place, not execute the work itself.
ASB or ASQ is your choice. This is where you need to choose between the features and capabilities each provides. There's a good MSFT comparison documentation on it.
Queues vs Topics/Subscriptions - if you need to send a message to a single destination (a command) then queue is simpler. In case a message needs to be broadcasted to multiple receivers (events), topics/subscriptions are your friends.
I have the following scenario in my project :-
The client makes use of ASP.NET Web API to make HTTP service requests. The Web API sits on top of a couple of WCF services, which in-turn handle all the business logic. The client subscribes to a particular type of event with the Web API. Whenever the Web API receives notifications from the internal WCF services about the occurrence of the event, the Web API in-turn needs to notify (push events to) all the subscribed clients about the events along with their details.
I want to understand the different options which are available for
sending asynchronous callbacks from an ASP.NET Web API to the
clients.(Currently we are working on a prototype for which the
client is a C# Windows Forms application. Later we might opt for
ASP.NET MVC4 web application.).
I also want to know which option would be ideal to send asynchronous
notifications back to the client when the data that accompanies the notification is of large sizes. In our scenario, the notification data that is sent back from the service may be of large sizes (~ in the range of 5KB - 50 MB).
In our scenario which I described above, can SignalR be used for notifying the c# client from Web API, as and when the Web API receives the callback from the internal WCF services?
Note :- The Web API is currently hosted in a Windows Service and the client is a .NET Windows Forms application.
Any pointers to such code samples or directions on how this can be achieved would be extremely helpful.
Cheers
SignalR is a good fit for the scenario you're describing, so I'd suggest using it for the notifications (especially since you want to start with a WinForms application and later switch to browser clients - with SignalR, you'll be able to connect to the same server-side code).
However, I'd also suggest keeping the notication messages lightweight, so instead of sending the data to the client with them, I'd send a token the client can retrieve the data with from WebAPI (SignalR isn't really ideal for large file transfers).