We have an application server that exposes a host of webservices. We are running a tomcat on the side that uses those webservices in JSF applications to provide a user interface. Suppose we have a bean that has a method "getWebservice()" that returns the proxy class used by jaxws to communicate with the webservice. This allows us to interact with the webservice with minimal effort: generate using wsimport, then use #{myBean.webservice.myProperty} etc
However as you can see this would require a lot of webservice interaction when reusing exposed methods. In our usecase most methods are rather static, at least for the duration of a #RequestScoped bean so the interaction of most methods should be cached once it is called (at least for one request).
Currently our setup is to create wrapper services in the bean and each wrapper does exactly the same thing:
if (methodResponse == null)
methodResponse = getWebservice().getMethod();
return methodResponse;
You can see that this gets very tiresome very quickly. Is there a way to annotate a jaxws method for caching? Or can I generate my own proxy class based on the interface and somehow "chain" it to the proxy used by jaxws (and perform generic caching) or can I create my own annotation that performs the caching?
You can create another caching Proxy around your web service client proxy object, and provide it with an InvocationHandler, that caches the result of method invocations.
Check out this blog post to see the complete step-by-step instruction and download sample code.
Related
I'm starting to choose a way to create my webservice, so i found 2 ways to do it:
1) Using the package javax.jws, with annotation #WebService:
#WebService(...)
public class MyServiceImpl {
2) The other way is using javax.ws, with annotation #Path:
#Path("/MyService")
public class MyServiceImpl
In my understand using the second solution is more simple, because when i need to create the Client i just need make a HTTP call (GET/POST). Using the first solution i need create a WSDL client, more complex solution.
So, I would like to know which is the advantage in use FIRST SOLUTION.
The SOAP/WSDL style is useful when a formal contract must be established to describe the interface that the web service offers.The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.
Also the SOAP/WSDL style is useful when the application architecture needs to handle asynchronous processing and invocation (e.g. using JAX-WS the assynchronous clients can be created).
The disadvantages of SOAP/WSDL style are
its complexity: tools are required to create a client
heavier on Bandwidth : SOAP requires a heavy XML wrapper arround each request or response
complicated security rules
The advantages of REST style are
simplicity: REST client can be accessed from any browser (however, this is only true for GET method. Data creation request requires also the XML wrapper).
lighter on Bandwidth : data on the wire are usually bare xml elements (not wrapped within the <Envelope><Body> tags).
REST application security rules can be setup using the http standards: the administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request.
For example, a GET request can always be considered safe because it can't, by definition, modify any data.
The disadvantage of REST style is that it still doesn't cover all business requirements
There is no common standard accepted yet for the formal REST service description
REST requests (especially GET method) are not suitable for large amount of data
REST doesn't cover all web services standards, like Transactions, Security, Addressing, Trust, Coordination,
Is it specified somewhere in these API
whether an instance of a MyService class is used
to serve many requests or a different instance is created on a per request basis ?
By what I've experimented It looks like that:
Frameworks implementing JAX-WS, instantate a new instance for
each SOAP request.
Meanwhile frameworks implementing JAX-RS, use the same instance to
serve different requests.
Also, in some cases I guess it is important to know whether a framework is allowed to
unload a service class to free space, does these specifications say something about that ?
thanks.
I am reading Professional XML
By: Bill Evjen; Kent Sharkey; Thiru Thangarathinam; Michael Kay; Alessandro Vernet; Sam Ferguson
Chapter SOAP & WSDl focusses on,
After you have found the service you want to consume, the act of discovery should bring you to the location of the Web service's WSDL file. The WSDL file is an XML description of the Web service's interface. After you have found the WSDL file of the Web service, you can create a proxy class (or your environment automatically creates one for you) that enables you to send messages back and forth to the Web service.
What is the proxy class in para above means and by whom it gets instantiated?
Is the Web Method which I wish to invoke through the SOAP constructed message format is also a method of the object of the proxy class?
The WSDL file is the technical contract which defines the communication interface with a service.
The "proxy class" in your citation, is just the logical representation of the service in your program. You can do this class by yourself, or have it made automatically. Most IDEs out there allow you to import a WSDL and they will generate most of the code needed to communicate with the service. The import tool will most likely create classes with methods and variables that correspond directly to operations and types in the WSDL file.
Your application instantiates the class and you call the methods you need to call by just filling the data as parameters and receiving the response in return. The class handles Object to SOAP message conversion for you. Keep in mind that even though it looks very similar to local function call, it is not - it is not nearly as fast and it involves network communication risks. It is quite possible to have communication errors that you need to handle.
I'm studying Jax-WS specification in general and its implementation on Glassfish 3.1.2. I built a simple standard example where a jax-ws soap based web service is called from a jsp page by using the artifacts generated through wsimport (the webservice and the jsp page are both deployed on Glassfish in the same EAR but in 2 different wars).
Everything works as expected but I have a question: looking at the application log, it seems that Glassfish creates a new instance of the webservice each time it is called. I would like to know where Java offically defines how a web container should manage webservice instances and if developers can customize this behaviour.
I read jax-ws 2.1 specification here
http://download.oracle.com/otndocs/jcp/jaxws-2.1-mrel2-eval-oth-JSpec/
but I found only a clue when speaking about how to publish a webservice using the Endpoint class by hand (section 5.2.2 "Publishing", page 69):
"An endpoint consists of an object that acts as the Web service implementation (called here implementor) plus some configuration information...
An Endpoint will be typically invoked to serve concurrent requests, so its implementor should be written so as to support multiple threads. The synchronized keyword may be used as usual to control access to critical sections of code. For finer control over the threads used to dispatch incoming requests, an application can directly set the executor to be used..."
This note is present even in Jax-WS 2.2 specification (used by Glassfish 3).
Actually, if I build a webservice using only JavaSE 7 (which includes Jax-WS 2.2), this description is true because there is only one instance of the webservice. Is there any reason why JavaEE doesn't follow this policy?
Thanks a lot for your help,
Nico
I found the answers on this specification (JSR-109):
http://jcp.org/aboutJava/communityprocess/mrel/jsr109/index3.html
It describes how Jax-WS works on JavaEE:
"4.1 Client Programming model (page 18)
a client must assume that the methods of a Web service have no state that is persistent across multiple Web service method invocations. A client can treat the Web service implementation as stateless.
The client has no control over the life cycle of the Web service implementation on the server. A client does not create or destroy instances of a Web service, which is referred to as a Port. The client only accesses the Port. The life cycle of the Ports, or instances of a Web service implementation, are managed by the run-time that hosts the Web service. A Port has no identity. This means that a client cannot compare a Port to other Ports to see if they are the same or identical, nor can a client access a specific Port instance.
5.3.2.4.2 Web container programming model for JAX-WS (page 42)
A Service Implementation must be a stateless object. A Service Implementation Bean must not save client specific state across method calls either within the bean instance’s data members or external to the instance. A container may use any bean instance to service a request.
5.3.4 Service Implementation Bean Life Cycle (page 43)
Before a request can be serviced, the container must instantiate a Service Implementation Bean and ready it for method requests.
A container may pool method ready instances of a Service Implementation Bean and dispatch a method request on any instance in a method ready state."
Moreover, the specification states that JavaEE must not use the Endpoint class to publish a webservice:
"5.3.3 Publishing Endpoints – javax.xml.ws.Endpoint (page 43)
JAX-WS provides functionality for creating and publishing Web Service endpoints dynamically using javax.xml.ws.Endpoint API. The use of this functionality is considered non-portable in a managed environment. It is required that both the Servlet and the EJB container disallow the publishing of the Endpoint dynamically, by not granting the publishEndpoint security permission."
I created a Web Service using JaxWs. I belive that exist two ways to consume a web service in the client.
using wconsume e putting the generated classes as stubs in the client.
using Dynamic Proxy, whitch means, there wil be no files to be send to client as stubs.
I imagine that the only advantage of this approach is that if the wsdl changed, there will be not need to generat stubs files. However it doesn't look too practical, as I will probably need to change something in the client code and recompiled anyway. I didn't use this tecnichy yet. I found this option when I was reaserching the reason why I need to generate proxy file when developping Java client but I didn't when I using .Net.
Then, I have two question:
What's the difference between stubs and Dynamic Proxy tecnich?
Why .Net client doesn't need proxies files? Or is there the files automaticlly generated and I don't know where to find? Am I loosing performance or security when using stubs versus dynamic proxy?
1.What's the difference between stubs and Dynamic Proxy tecnich?
JAX-RPC is deprecated.
The new standard is JAX-WS.
JAX-WS allows programmers to invoke a web service, as if they were making a local method call.
For this to happen a standard mapping from WSDL to Java has been defined.
This mapping correlates a wsdl:port definition with a Java Interface which is called Service Endpoint Interface (SEI).
The SEI is the Java representation of the web service endpoint.
At runtime JAX-WS creates an instance of a SEI that can be used to make web service calls by simply making method calls on the SEI.
Now the way used to create an instance of a SEI is via the dynamic proxy class.
It is called dynamic proxy since it is created dynamically.
No stubs are need to implement a proxy, but the SEI must already have been implemented in order to be used.
The proxy uses/is based on the stub classes to function, which have been generated by the WSDL.
So the stubs are a prerequisite.
So there is no separation of techniques as you say in your post.
You have misunderstood the concept