I want to build an architecture in which one vertx-based backend microservice can send a file (which it receives from some UI) to another microservice.
I know that vertx web client would allow sending multipart data form, or streaming but not both. The UI (created with reactjs) can do it easily but the same does not apply to vertx.
Does anybody know how this could be achieved?
Thank you!
from the backend vertx application you should be able to create a vertx client which will post a file.
https://github.com/vert-x3/vertx-examples/blob/master/core-examples/src/main/java/io/vertx/example/core/http/upload/Client.java
Related
I have a wsdl file in a Spring JMS project, where i need to create an XML to sent to a queue. This xml should look like a SOAP Message including Header Body and whole Envelop. I don't understands how not to implement a SOAP WebService but still create a XML SOAP structure. I don't want to create whole structure using SOAP Element classes where i have to write a lot of code and each time if my Java Object updates i have to update this implementation as well, thanks for help.
See the Spring Web Services Reference Manual (specifically JMS Transport on the client side).
For sending messages over JMS, Spring Web Services provides the JmsMessageSender. This class uses the facilities of the Spring framework to transform the WebServiceMessage into a JMS Message, send it on its way on a Queue or Topic, and receive a response (if any).
To use the JmsMessageSender, ...
How to process the webservice XML message in Mirth Connect 3.x?
If I understand your question correct, you are asking for how to configure Mirth to become a Web server. It's actually easy and hard at the same time.
The easy way - create a new channel and configure the Source connector as Web Service Listener. Deploy the channel and you have a web server waiting for SOAP messages to be sent to a configured IP port. But the structure of these SOAP messages is governed by Mirth WSDL at localhost:8081/services/Mirth?wsdl.
If you want the SOAP message structure to be different then you are going to deep dive into creating your own Java class and overriding default web service methods. There is no a single answer for that, it is a completely separate topic.
I hope you are asking how to consume XML webservice message in Mirth?..
If you are receiving specifically SOAP you need to set webservice listener as your source channel listener. (as said previous answer, you will have the URL)
Go to your transformer and type the following code:
logger.info(connectorMessage.getRawData());
Once you do this you can see the data you received inside Mirth on the logger area.
I am new to Mule. I am using RabbitMQ. In my Mule studio, I have configured AMQP in Mule studio.
I am able to run a flow where I put one message read from HTTP endpoint payload and put into a queue.
Now, I need to send multiple messages, say 1000, to that queue at a time. One option is that I hit the url in the browser that many times but that is very time consuming. I want to send 1000 messages at one go. How can i do that in mule? or How should I proceed with it?
It sounds like your trying to load test your Mule app. I would use something like Apache JMeter. JMeter will allow you to enter the url of your endpoint and set how many times to call it and many other more advanced features.
A good blog post on using JMeter and Mule is available here: http://blogs.mulesoft.org/measuring-the-performance-of-your-mule-esb-application/
I have a project that is currently in production delivering some web-services using the REST approach. Right now, I need to delivery some of this web-services in SOAP too (it means that I will need to deliver some of the same web-services in SOAP and others a bit different), so, I ask you:
Should I incorporate to the existent project the SOAP stack (libraries, configuration files, ...), building another layer that deliver the data in envelopes way (some people call it "anti-corruption layer") ?
Should I build another project using just the canonical model in common (become it in a shared-library) ?
... Or how do you proceed in similar situations ?
Please, consider our ideal target a SOA architecture.
Thanks.
In our projects we have a facade layer which exposes the services and maps to business entities, and a business layer where the business logic is run.
So to add a SOAP end point for an existing service, we just create a new facade and call in to the same business logic.
In many cases it is even simpler, since we use WCF we can have a http SOAP endpoint for external clients, and a binary tcpip endpoint for internal clients. The new endpoint can be added by changing the configuration without any need to change the code.
The way I think about an SOA system, you have messages and pub/sub. The message is the interface. Getting those messages into and out of the system is an implementation detail. I create an endpoint that accepts a raw message document (more REST-like, but not really REST) as well as an endpoint that accepts the message as a single parameter to a SOAP call. The code that processes the incoming message is a separate concern from the HTTP endpoint enablement.
You can use an ESB for this. Where ESB receive the soap messages and send the rest request to the back end. WSO2 ESB provides this functionality. Please look at this sample[1].
[1] http://wso2.org/project/esb/java/4.0.0/docs/samples/proxy_samples.html#Sample152
I have a question about the design of an application I'm working on.
I made a monolithic java application with sockets open 24/7, something like a game server. I'm just trying to say it's a single jar application instead of a modular servlet/page based web application.
I would now like to add a RESTful API to this application. So people/clients can make HTTP requests to my application to obtain certain info. Because of the monolithic nature of my java application I'm unsure of how to implement this. One other important thing: I'm expecting multiple requests per second, so it would be nice if I could have an existing http server handle the requests, and somehow forward them to my app to set up a reply, and have the http server send it again.
Some things I have thought of:
wrap my application in a tomcat application, although I'm not sure if tomcat can run an application continuously instead of mapping to servlets on request.
open a socket and parse incoming http requests myself (or there is propably a lib for that?). I fear this will have an impact on performance, and would rather use existing http servers because they are optimized for high traffic.
use an excisting http server to handle the requests (apache, lighttp, ...) and have it forward requests to my app via things like scgi, or use a server that can forward via XMLRPC. Are there any other technologies/protocols to do this?
Any advice on how to handle this?
Thanks!
I'd decouple your RESTful service endpoint as much as possible from your original application. This allows you to scale (add multiple servers for your REST endpoint), but also to change your original application without having to change your REST API directly.
Clients <== REST (HTTP) ==> RESTful endpoint <== legacy (sockets) ==> Legacy backend
So your REST server is one the hand a service provider for your clients, but represents at the same time also a client for your original backend.
I would design the RESTful API and then pick one of the existing REST frameworks for Java, like Restlet, and implement the REST service itself. At the same time you can start implementing a gateway between the REST server and your original backend, by using sockets.
Pay attention to scalability and performance (i.e. you may want to use connection pools for the rest <=> backend bridge and not spawn a socket per incoming API request) and also think of possible advantages of HTTP. You might benefit when you're able to use caching, etc. as far as your backend application logic allows so.