We Keep Coding

HTTP Basic authentication seems to fail with JAX-WS client

I am making a call to a soap web service, using a jax-ws client generated with cxf-codegen-plugin.
The web service i am calling implements a HTTP basic authentication, so I use the following properties in my request context to fill username/password :
Map<String, Object> requestContext = bindingProvider.getRequestContext();
requestContext.put(BindingProvider.USERNAME_PROPERTY, username);
requestContext.put(BindingProvider.PASSWORD_PROPERTY, password);
The problem is when the calls are executed no response is received, and no error is logged.
The request is logged but then the http connection seems to remain active while nothing happens. The web services respond correclty with soapUI so the problem is definitly in the client side.
I think the HTTP headers, which are supposed to hold the username/password are not sent properly, because the following line returns null :
soapMessageContext.get(MessageContext.HTTP_REQUEST_HEADERS))
Thanks in advance for any help.

You need to add a soap header for authentication:
http://javajeedevelopment.blogspot.fr/2011/01/how-to-add-soap-header-using-jax-ws.html

WebService Client in Java

I have the following problem: I am completely new to java EE (know only about servlets and JSPs) and especially web services.
I need to develop a client for a web service (it needs to query the service for useful information once in a minute).
In my mind this client would be a simple java-SWing-based program, which would query the web service through simple Socket when the application client runs. How can that be done?
Is it possible to do in that way? If not, which is the easiest way to create such a client?

I would suggest using Apache CXF. Simple and powerful framework.
And yes, that is possible to implement what you said using this framework. Just read tutorials and play around for a bit with it.

Inorder to connect to a web service using a java client follow the below mentioned steps:
1. Get the URL in which the webservice is hosted. This is usually of the fomat http://<IP_OF_SERVER>:<PORT_OF_SERVER>/<WEB_APP_NAME>?wsdl
2. Get the qualified name of the service:
// 1st arg is the service URI
// 2nd is the service name published in the WSDL
QName qname = new QName(<Service_URI>, <SERVICE_NAME_PUBLISHED_WSDL>);<br/>
3. Create a factory for the service:
Service service = Service.create(url, qname);
4. Extract the endpoint interface, the service "port":
<Port_Class_Name> eif = service.getPort(<Port_Class_Name>);
5. Now use the methods on the Port, which are the actual methods in your webservice.

You might want to try REST Webservice, try Jersey REST (or others). With rest you can connect it with http connection (GET and POST).

Inorder to connect to a web service using a java client follow the below mentioned steps:
1.URL wsdlUrl = new URL("your wsdl url);
2.QName qname = new QName("targetNamespace in ur wsdl file","service name in your wsdl file");
Service service = Services.create(wsdlUrl,qname);
4.suppose getData() is your SEI
GetData data = (GetData)service.getPort(GetData.class);
5.call the your methods using data object
ex:data.getId(String name); this will return your response

Jersey REST:How to write a jersey method including verifying HTTP Authorization

I am writing a Restful webservice method,which require authorization first...
such as a findItems method..which need username and password in Http Authorization
the sample code:
#GET
#Produce(MediaType.APPLICATION_JSON)
public String findItems(){
...
}
how to verify the http authorization before the method excutes...

I use a user-type and role-type control with a basic JAAS authentication. After authentication, the client makes http GET requests to the REST web service. In my Facade get method, I inject the #Context SecurityContext as input parameter, and use if for user / role identification in order to provide the correct answer to the GET request, depending on the user's role.
See here for an example of what I mean:
Using JaaS with Jersey on Grizzly

you can use Filters so you can check the authorization

How can I manage users' sessions when I use web services?

In case if user works with web application via web browser, the user's session is managed by application server. It takes care of sessions creation, validation, timeouts, disposings, etc.
And as far as I know there is no such mechanisms in the other case, if user works with app via remote client and uses SOAP web services.
So the question is, how can we manage users' sessions in case of web services and implement the same mechanisms of session management such as invalidation, prolongation, disposing?

Assuming you use JAX-WS and SOAP/HTTP it is possible to work with container managed security (and e.g. session cookies) as well. You just have to inject WebServiceContext in your service. It allows access to all HTTP environment variables:
#Resource
WebServiceContext wsContext;
A detailed example is available here. Of course, your clients must support this as well (if they are JAX-WS based it works). Nevertheless, a rule of thumb is that web services should not maintain any state at all, they should behave stateless. See this on SO.
Edit: You can access the ServletRequest by:
#WebMethod
public void foo() {
final MessageContext mc = this.wsContext.getMessageContext();
final ServletRequest sr = mc.get(MessageContext.SERVLET_REQUEST);
/* works if this is a HTTP(s) request */
if (sr != null && sr instanceof HttpServletRequest) {
final HttpServletRequest hsr = (HttpServletRequest) sr;
hsr.getSession(true);
/* ... */
} else {
/* do some exceptional stuff */
}
}
The session created above should behave in exactly the same way as a 'standard' web session. You must make sure that your clients understand that as well. They have to submit the session identifier (cookie) on each subsequent call.

I think you are talking about how to maintain web-services session(state-full web-services).
In this case following link can help you:
https://blogs.oracle.com/sujit/entry/ws_addressing_and_stateful_webservice

Web Service does not support session state for achieving high scalability, web service is designed stateless.
Session state handling is not a part of SOAP specification. The cookie stores a token which acts as session identifier. There are a number of ways to pass the session identifier: as an HTTP cookie, as a SOAP header, or as an element in the SOAP message body.
A SOAP header is transport independent, but it requires the SOAP client and service to agree on the format of the SOAP header, and it required that both the SOAP client and SOAP server implementations support SOAP headers. If you use the SOAP body to pass the session id, then it's up to the service (i.e., your application code) to re-establish the state on each call. Stateful processing can make cross-SOAP interoperability a bit more challenging, but it does work. Check into the capabilities of your SOAP implementation. source

Can we retrieve the requestor details through a SOAP call using Apache CXF?

We are getting a SOAP request on our server from various systems. Before sending the response , we need to make some new requests to the requesting system to fetch some details. To do so, we need to determine the details of the requesting server. Is there a way to detemine:
- Requesting System VIP
- Requestor IP
- Other requestor specific details

If you use JAX-WS API, you can use WebServiceContext to retrieve message meta-data. Just inject a reference into your implementation:
#WebService(name = "MyService" /*...*/)
public class MyService {
#Resource
private WebServiceContext wsc;
#WebMethod
public MyResponse process(MyRequest request) {
HttpServletRequest httpRequest = (HttpServletRequest) wsc.getMessageContext().get(MessageContext.SERVLET_REQUEST);
httpRequest.getRemoteAddr(); // access some parameters...
return new MyResponse();
}
}
It allows you to access 'everything' that came along via the HTTP request like caller address.

I assume the Soap service is based on Http protocol. You can use HttpServletRequest's getRemote...() methods. But I am not sure whether that information will be enough for you. Another option would be to ask the client to include the client information that you need in their requests.