Right now, I have deployment that is supposed to call web service externally on localhost:7001. I know in my body I will add the xml containing the service I need along with username/password for credentials. But actually calling my web app, I'm not sure how to get the endpoint URL.
You can check endpoint in Weblogic Admin Console
I need to build some web services in a WebLogic application server. This server lies between a mobile app and Oracle ERP. Basically, after the mobile app "login" to the Oracle ERP via a web service call on the application server, a session should be maintained on the application server. One reason is this:
Every time a web service is called by the mobile app, it needs to return a random challenge token. This is a requirement by our internal security. Within the same session, when the same mobile app calls the same web service (or a different web service) on the application server, it needs to pass the challenge token that it received previously. The application server will then have to check that the token is the same one that it returned previously to the mobile client.
We have discussed about using JAX-RS for communication between mobile app and the web services. However, I have read that JAX-RS is supposed to be stateless. In this case, how can I maintain a session such that the application knows the challenge token that it returned to a client previously? There is no database for the application by the way. Normally for a web application, it can just save the challenge token to a session object, but how do you do so for a web service?
If JAX-RS cannot maintain session, then what about JAX-WS?
Thanks.
I need to clarify some problems regarding soap web services.
1) can I call a soap web service by just typing the url of the endpoint in the browser?
2) does the answer for question depend on what type of technologies used to develop the soap web service?
If I need to invoke a soap web service, i need to send a soap request. But by just sending a get or post request from a browser cannot generate a soap request. so by default I shouldn't be able to invoke a soap web service just using the browser.
but the following two resources are contradicting above assumptions of mine.Can someone explain me how these soap web services can be invoked without a soap request?
https://msdn.microsoft.com/en-us/library/aa719483%28v=vs.71%29.aspx
http://alvinalexander.com/blog/post/java/how-to-call-web-service-from-browser
To casify web service I am planning to follow the following:
I have a application that requests for a web service, the web service will only server the client if the application passes a valid ticket string.
The Java application sends a username/password combination to the CAS server using restful API.
The CAS server replies with a ticket on successful authentication.
The application sends the ticket my web service and ask for some data for some data.
The web service receives the ticket and sends the ticket to the CAS server to validate it.
If the CAS server returns a username/ or any kind of message that confirms the validity of the ticket, the web service replies back to the application a response to fulfill the application request.
The CAS server is returning the ticket to the application,the application posts the ticket string to web service, the web server accepts the ticket string. Now how do I send the ticket to CAS server for validation? Any ideas? Also is there any better way to casify the Web service?
I tried to draw what I want to archive:
Since this is a java based application you can use the filters that are available with CAS to do the validation & authentication.
What does it mean when a web service is asynchronous? Is this only used when you call it with Ajax and you have a part on your page that refreshes when the web service is done? Thank you.
I know this is an old topic, but whether a web service is synchronous or asynchronous depends on the design of the web service and has nothing to do with Ajax. An asynchronous web service transaction proceeds like this:
The client calls the web service. In the call the client sends a callback end point implemented as a service by the client.
The web service returns a "message received" reply.
...
(Some other processing occurs)
...
The web service completes its task, then calls the callback endpoint provided by the client.
The client callback replies with message received.
See Developing Asynchronous Web Services or How to: Create Asynchronous Web Service Methods
The question is whether it's the web service that's asynchronous, or your access to it. In the context of a web page, it's more likely that the service is synchronous, but that it is being accessed asynchronously.
Most likely, the service is being called via AJAX. The call is made to the service, and the page then continues. When the response comes in, either the success or the failure functions are executed, asynchronously.
Synchronous means that you call a web service (or function or whatever) and wait until it returns - all other code execution and user interaction is stopped until the call returns. Asynchronous means that you do not halt all other operations while waiting for the web service call to return. Other code executes and/or the user can continue to interact with the page (or program UI).
So, I would not say that the web service itself is asynchronous, I would say that your ajax call to the service is asynchronous.
When you call synchronous web service the service processes the request and return HTTP status code 200 OK (1) if everything went as expected, or error 4xx. The call is blocked while processing and the request and can take significant time.
When web service is asynchronous the main difference is that call should return instantly with HTTP 202 ACCEPTED (2) which means that request is taken in queue but not processed yet.
(1) 200 OK http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1
(2) 202 ACCEPTED http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3
An asynchronous web service allows a client to submit a request, process the request and respond to the client after a given time -- the client would not block all activity on receiving a response.
Comparatively, a web service that is synchronous would provide a client directly with a response, expecting the client to block all activity until a response is returned. In this case the web service would limit the client to process requests one at a time.