We Keep Coding

Is it possible to communicate between different rest clients using a common API of another application?

Let's say we have three applications called A,B and C B is an email sending application,and it has a method to send an email like sendEmail(String email) now I need to call that function from A through the rest API of C(Here A and B are rest consumers who can use C as a Common API).Can I do something like that?. I mean you can see there is no any direct communication between A and B so I am simply asking can I use rest API as the one who links them ?I know there is rest template and other rest consuming technologies available to do the consuming tasks,but in all those scenarios there is only two way data exchanging ,which is most probably with a client and a server(Rest service provider and consumer) and there won't be something like server is calling the client,because in every time client is calling the server methods(Get,post,put,delete) .but here you can see we need some kind of a method to call the sendEmail(String email) function of email sending application through the server so basically to do so server(Rest services provider) needs to have an object of that email sending application.How is this possible?
If you doesn't understand the scenario please tell me at-least is it possible to invoke a method of a rest consumer from rest API(rest server)? , because normally we call the methods of rest API from rest consumer [I am using spring boot]

In any case you need to invoke REST method to invoke your sendEmail method because you client is also a REST client and it can communicate with REST method

If you need A to call B directly, you need to have B expose the email sending capability as a REST Endpoint if it doesn't already exist.
Then you can use the Spring Rest Template capability to call application B from A. Make changes to A to use Spring Rest Template and then make the relevant call.

What is service activator component in spring integration?

I am learning spring integration reading/watching a different stuff but I can't understand what service activator is.
I understood that there are two types of integration:
chanel and gateways. chanel is unidirectional integration but gateways is request/reply model. Gateways can be inbound(our system gets request and sends response) and outbound (our system sends request and receives response)
When I read about gateways I often see termin "service activator"
Could you clarify what does it mean ?

The outbound gateway is essentially a particular case for a service activator abstraction for request/reply scenarios. Another case is an outbound channel adapter, which is a one-way, but still can be treated as a service activator because when we send a message to its inputChannel, we are going to call some code - which we can treat as a service. Therefore activating it.
A general component service activator exists there for all the use-cases which are not covered by particular implementation. Let's imaging you need to call some REST service. Right, you can use an HTTP Outbound Gateway with some specific options. Or you can write some custom code which uses a RestTemplate to call that service. you wrap your code into a service activator configuration and you end up with the same behavior for the whole integration solution.

A service activator is a call to a method in a bean.
<service-activator ref="myService" method="aMethod"/>
will call
#Service
public class MyService {
public A aMethod(#Header(value = "param1") String param){
//code
}
}
#Header annotation allows to use an existing value in the header. That is an example.
You can also use it like this:
<service-activator expression="#myService.aMethod('My param')"/>

Jersey client creation in a REST service

i am creating a http REST service that consumes other http REST services.
I am using Jersey Client to call other services and i have many doubt about which creation pattern of the http client is the best.
Currently i am using EJB with injection of the client that is a Singleton shared by every methods, but i would like to remove java ee dependency and use Jetty as embedded application server.
I see from the doc that Client creation is an expensive operation so i cannot create one every time i need it.
I think about creating 1 in the constructor of every Servlet/Rest class is the simpler solution but i am not sure about the lifecycle of the servlet (if an instance is created for every request, this method is quite the same as the previous)
Or maybe is better to create a Singleton shared by every Servlet/Rest class
Or maybe better a pool of N client.
About this last two solution i need some advice... What do you think it's the better solution?
Thanks

According to you, there is a REST Service deployed in some environment and there is one application, a client or consumer, which wants to access that service.
If i am writing a normal Java class as client using Jersey API, then i will write something lime this :
import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
import com.sun.jersey.api.client.WebResource;
Client client = Client.create();
WebResource webResource = client
.resource("http://localhost:8080/rest/example/employees");
ClientResponse response = webResource.accept("application/json")
.get(ClientResponse.class);
String result = response.getEntity(String.class);
Now say you are writing a servlet, which does some defined job in you application, also it makes a call to the REST Service using client block of code, everytime you access the servlet it will create a instance of com.sun.jersey.api.client.Client each time.
If you want to avoid this then you can create a initial class that will create an instance of com.sun.jersey.api.client.Client, one and only, and make it static and use the same reference where ever you want. WebResource should be created as and when required, because you might be interested to call different URIs.
I would have followed this approach, if i were in your situation.

Interservlet communication

I have a Websocket servlet and a Rest servlet.
I want to inform the websocket servlet about changes in order to write these "events" via websocket to a server.
I could only find the forward() and include() approach. But they seem to me that they only can forward onGet, onPost, etc.
do I miss something?

Indeed, forward() and include() are meant to be used when processing a request. So they might not be the best option given what you want to achieve.
What you could do is create a third component, let's call it EventManager for the time being, and have the Rest servlet signal changes to the EventManager. The websocket, on the other hand, could be notified by the EventManager that new data are available and then get that new data in order to write it back to the client.
In this approach it is essential that both the Rest servlet and the websocket servlet share the same instance of the EventManager. You could achieve that by marking the EventManager as a singleton EJB by adding the #Singleton annotation, and inject it to both the Rest servlet and the websocket servlet.

Metro with jax-ws override endpoint address

I'm creating a webservice client using Metro with jax-ws and I want to override the endpoint address.
Using the following example from 2.11.1. BindingProvider.ENDPOINT_ADDRESS_PROPERTY I can do that:
http://metro.java.net/guide/How_to_invoke_and_endpoint_by_overriding_endpoint_address_in_the_WSDL.html
//Create service and proxy from the generated Service class.
HelloService service = new HelloService();
HelloPort proxy = service.getHelloPort();
((BindingProvider)proxy).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"http://new/endpointaddress");
proxy.sayHello("Hello World!");
But I don't understand why I can't use the service.getHelloPort().sayHello("Hello World!") instead of proxy.sayHello("Hello World!") as the example shows. If I do, the webservice client is using its default endpoint address instead of the one I want to use.
It looks like I'm getting a new instance of HelloPort every time I call getHelloPort()
Can anyone explain this?

there is little (read: no) difference between these:
service.getHelloPort().sayHello("Hello World");
and
HelloPort proxy = service.getHelloPort();
proxy.sayHello("Hello World!");
the service.getHelloPort() call will always return a new proxy/port instance. so any time you modify the request context for a given port object that modification is local to the specific port instance.
generally speaking the port instance you get back is re-usable and thread safe as long as you dont modify the request/response contexts. for the code sample you posted, it is modifying the request context to set the endpoint address, so it is advisable to get a new port object either every time you need one, or at the very least get a new object for each thread that needs one. (threadlocal is your friend for this)