I want to use apache CXF to build my client. Unfortunately, I do not see a way by which it allows me to dispatch a client dynamically based on the port and operation name. If there is a huge wsdl, JaxWsDynamicClientFactory would create classes for all services contained in it which is an overhead that I'd like to avoid.
I found a similar implementation in JAX-WS. Is there any api in CXF that would do the same?
CXF supports the JAX-WS Dispatch API, which is a low-level interface to SOAP.
That means you can create a Dispatch that represents a particular port-type on a service and then invoke the methods by building the message
// Set things up...
Service s = ...
Dispatch<DOMSource> dispatch =
s.createDispatch(portName, // << a QName!
DOMSource.class, Service.Mode.PAYLOAD);
// Construct the request message here
Node response = dispatch.invoke(new DOMSource(request)).getNode();
// Understand the response message here
Of course, that then means you've got to work with the DOM for the messages, which is highly annoying. I think that's the part of tooling that's really worthwhile.
Related
I wrote some micro-services using Quarkus that communicate via Artemis. Now I want to add OpenTelemetry for tracing purpose.
What I already tried is to call service B from service A using HTTP/REST. Here the trace id from service A is automatically added to the header of the HTTP request and used in service B. So this works fine. In Jaeger I can see the correlation.
But how can this be achieved using Artemis as messaging system? Do I have to (manually) add the trace id from service A into the message and read it in service B to setup somehow the context (don't know whether this is possible)? Or is there possibly an automatism like for HTTP requests?
I would appreciate any assistance.
I have to mention at this point that I have little experience with tracing so far.
There is no quarkus, quarkiverse extension or smallrye lib that provides integration with Artemis and OpenTelemetry, yet.
Also, OpenTelemetry massaging spec is being worked at the moment, because the correct way to correlate sent, received messages and services is under definition at the OTel spec level.
However, I had exactly the same problem as you and did a manual instrumentation that you can use as inspiration: quarkus-observability-demo-activemq
It will correlate the sent service as parent of receiving end.
I am working with ActiveMQ. I want to put gRPC calls as a message on ActiveMQ. As soon as consumer picks a message the gRPC in the message should execute.
gRPC calls take parameters so I want to understand how to send these parameters in the message body along with the method name/identifier. Is there any another way of achieving this which is followed already?
Example:
someResponse response = someStub.rpcMethodName(parameter); // grpc call
What I need is to store this statement in some format on ActiveMQ without calling the gRPC now. Then in the future when the consumer of ActiveMQ picks up the message containing this statement it should execute this gRPC call.
You can structure the gRPC call data in your message any way you want. You could use XML, JSON, ProtoBuf, etc. It's really up to however you want to do it. If all you really need are simple key/value pairs then you could just use JMS message properties to store the data you need.
I don't think using gRPC is particularly common, but it is common to use messages as a kind of "unit of work" to work with all kinds of remote resources (e.g. databases, REST services, microservices, etc.).
In any event, I would strongly recommend against using JMS ObjectMessage. ObjectMessage objects depend on Java serialization to marshal and unmarshal their object payload. This process is not only slow but generally considered unsafe because a malicious payload can exploit the host system. Lots of CVEs have been created for this. There are a number of other issues with using JMS ObjectMessage not related to security that you should read about as well.
I have a small Java SE application, it´s practically a fat client sitting on top of a database. To further my Java skills, I decided to make a client-server application out of it. The server application communicates with the database and handles all kinds of lengthy operations, while the client application only receives the results, mostly ArrayLists of moderate length and primitives.
To this end, I started reading on RMI and did the Oracle tutorial, which I found surprisingly difficult to understand and even get to work.
Is there anything else I can use instead of RMI, without having to dive into JavaEE?
One way I would suggest would be to use JSON as the format for data exchange. You can use GSON to convert the data from Java objects to JSON and back. The transport could be done directly on the HTTP protocol using REST. You can use Jersey as a REST server/client or roll your own (since you don't want to use JEE, which Jersey is part of).
SIMON is as simple to use as RMI, but with fewer traps in the initial setup. It also has some advantages over RMI. Here is a simple hello-world example:
http://dev.root1.de/projects/simon/wiki/Sample_helloworld110
I take it RMI = Remote Method Invocation ...
You can have a look at XMLRPC, JSONRPC, JMS, or if you want to roll your own, use JSON to POST messages and convert the JSON back to a java object on the other side using GSON (from Google) or setup RabbitMQ and use AMQP to submit and receive messages if you don't want to handle the POSTing yourself, Spring AMQP makes it fairly easy to do this.
I have requirement something like this:
once the request is received by my service, i need to send it 2-3 third party servers at a time and get the response from all server and return the response.
How can I achieve that?.
My thought : I can create separate threads for different servers and send the request to all servers parallely, but here the issue is, how I will come to know the threads are finished and consolidate the response from all servers and return to caller.
Is there any other way to do in spring boot(micro service)?.
You can leverage asyn feature supported by Spring Framework. Let's see the folllowing example which issue multiple calls in Async style from Spring's official guides:Async Method
Another possible solution for internal communications between Microserives is to use the message queue.
You didn't specify what type of services are you consuming. If they are HTTP, you may want to use some Enterprise Integrations abstractions (most popular are Spring Integration and Apache Camel).
If you don't want to introduce message bus solution into your microservice, you may want to take a look at AsyncRestTemplate
I have a Java EE application where the model is updated very frequently from various sources. In addition I have a rich client application which triggers some actions via remote EJBs but which should also display the model changes ate least every second.
What is the easiest/ best option for sending the changes from the Java EE application to Java client application? Till now I have the following options:
polling a remote EJB every second from the client
polling a servlet (Is it preferable to use json/ xml instead of java object serialization? Any other serialization?)
websockets (Is it possible to send Java objects here? Or must the result be serialized to Json for for example?)
tcp socket connection (The server would provide a port where the client connects to on startup. Model changes are send via standard object serialization. Is this "allowed" in a Java EE app?)
Option 1 is the easiest one, you can use there asynchronous EJB methods:
SERVER
#Asynchronous
public Future<String> getUpdatedModel() {
//here create blocking process until something interesting happen
return new AsyncResult<String>("model has changed!");
}
CLIENT
Future<String> updatedModel = bean.getUpdatedModel();
while(true){
String response = updatedModel.get();
//process response here
}
Option 2 looks like option 1, but you have to take care of marshaling objects, so don't bother in using plain servlet.
Option 3 looks interesting, as websockets are going to be included in Java EE7 (now you can use opensource comet implementations for servlets). In my opinion it is not designed for communication in enterprise applications, but might be fine for your usecase. There is a plenty of JSON serializers available (e.g. gson), I use that kind of communication between JS and java, and works fine.
Option 4 breaks major Java EE principles (opening your own sockets is forbidden), and I would discourage you to use it.
Option 5 Listen to Xie and use JMS! If you will use JMS topic, you could just send the message when particular event occur, and all connected client will receive the message asynchronously. It is natural Java EE way of solving this kind of problems, with out of box transactions, message redelivery and persistence if nessesary.