I'm working on a project with JAX-WS.
When I annotate my endpoint class with #WebService the WSDL is marked in console like
.../<context-root>/XXXService?wsdl
When I add #Stateless on those endpoints the WSDL is not marked in console and the actual address is
.../XXXService/XXXEndpoint?wsdl
Is this normal or expected?
Update
For further readers.
I couldn't find any resolution. I decided not to use mixed #Stateless+#WebService. I split those #EJBs and #WebServices for clear module separation.
What youre experiencing is expected behaviour. It's a different matter if the service s not functional. When an EJB 3.x stateless bean is deployed as a WS, it's naming defaults to what you see there,
Servername/SIBnameService/SIBName.
The reason for this is obvious: EJBs don't operate within the context of a web application and so cannot be addressed as such. You can customise the default name using the serviceName attribute on the #WebService annotation
Look at this from apache
Related
Is it mandated by any standard that a web service should provide a WSDL by appending ?wsdl to the endpoint address?
Is it OK if the WSDL is hosted at a different URL (without appending ?wsdl)?
For example:
Endpoint: http://abc.xyz.com/MyService
WSDL: http://abc.xyz.com/MyServiceDefinition.pqr
Note that I'm even using a different extension for the WSDL definition.
Does using this approach violate any standards or one can host the thing the way they want?
Is it mandatory to have a WSDL definition accessible using ?wsdl?
No, it's not.
A WSDL is used to describe a web service contract and is provided because it allows tools to automate generation of client stub code for calling the specified web service. Exposing the WSDL at the same location as the web service with ?wsdl appended to it is just very handy and that's the convention everybody uses.
People and tools look for the WSDL at that location and frameworks automatically expose it at that location but it's just a convention. As to my knowledge this isn't specified in any specification (or at least none that I could find).
Sometimes though you don't want to provide a WSDL that everybody can look at and try to create a client because it's a private web service and you only want to give access to your partners, not to everybody. At that point you can disallow the ?wsdl URL and provide the WSDL only to your partners by using an alternative channel. You can even e-mail it if you don't want it exposed online.
So you can choose whatever channel to expose it. Just remember that because people and tools are following this convention they are used to see it there and some (poorly written) tools might choke in a different extension, for example.
P.S. One other thing I wanted to mention - which isn't strictly related to this answer but kinda reinforces the convention - is the new ?singleWsdl option in WCF 4.5.
WCF, as most other tools, exposes the WSDL at the ?wsdl address but uses xsd:import statements with external schemas. Some frameworks were not able to process WSDL with imported dependencies so people started to write customizations over WCF to have a flat WSDL exposed, so much so that in the latest version of WCF Microsoft decided to add this feature out of the box.
But for backward compatibility they needed to keep the ?wsdl endpoint as it was (returning a WSDL document with xsd:import statements inside) and were forced to add a new query parameter for the flat WSDL: ?singleWsdl. I'm sure this idea will be picked up by other web service vendors and providers as well.
No, Its not mandatory to have ?wsdl access, but its recommended way.
Its worth noting that most clients will try to append "?wsdl" to your URL and will try to access WSDL file, Hence its highly recommended to setup it.
I have few questions with respect to portlets and servlets. This may be a continuation of
my previous question.
I m trying to create a portlet which should act also as a web service. I dont know Why,
but the client requires it this way. I negotiated with the client that I can make a
separate web service application using simple jersey servlet... but cannot convince.
I have the following doubts:
A portlet by itself cannot represent independently to the outside world. If that is
the case then what is the benefit in making a portlet as a webservice than not making a
complete webservice project with just servlets?
By web searches, I came across few code sample which can make a portlet as a
webservice. These sample codes suggested me to create a portlet, in the web.xml include the jersey-servlet and servlet container to make the portlet as a web service. Though it might work(I m trying hard to make a working codebase) but why to include a servlet container inside the portlet container which is already residing inside a servlet container. Sounds confusing? The following image can convey by doubt:
In this the liferay is a the servlet which is visible to the browser first. This has
multiple portlets in it. If I am making a portlet as a web service then I have to make it
visible to the browser, so I m including a servlet inside the portlet(Its my assumption
according to the sample code from web). This is like taking a round trip to touch my nose.
I really dont understand why this architecture is like that. The following points which I
guess is sensible for making a portlet as web service are:
(i) If I make a servlet(a separate project) for web service then (working as a liferay developer in the team) we cannot claim this as a liferay project.
(ii) If the web service is a portlet then I can have inter-portlet communication. In case of servlet it cannot(if I m not wrong).
Please suggest.
I think this can drive you to what you need. A portlet can be called in a EXCLUSIVE mode, where no portal or portlet content are generate in the response. So you can produce whatever "HTML" or data you need as a response.
Im researching and starting with Restful, but it seams like a request/response HTML communication. The main difference is the annotation that map an HTML to a Class and methods in standard modes. In liferay you can assign an URL to your portlet. It can produce a behaviour like the one in Restful.
Am new to web services. I have a spring bean in which i have used Transactional annotation for DB operations.
Now I need to expose one of the method in the bean as a service.
The method parameters are Hashmap and a POJO (like JPA entity) object. return type is HashMap.
What is the best way to implement it.
Directly exposing the bean using Axis2.
Using Spring-Ws with CXF.
Writing a new method in a new wrapper class which accepts Strings as parameters.
(These string are actually as required by the original Map and POJO ).
And by setting these strings as properties and objects in POJO and Map respectively, as required by original method.
The Third method wont work in my case as the Map will contains several arraylists which needs to be stored in DB.So I have to use Map only.
Shall I go with SOAP or RESt.
Already two web services were provided using Axis2 in our project by old team.
We are using spring 3 (as core container and for ORM), Hibernate template, Tomcat 6.
Well, that question is best answered by yourself. We can only give hints here which framework and technology might work out best for you. In order to give any hint, we'd need some more information about your project.
SOAP and REST, for example, are two essentially different technologies. The SOAP protocol must use XML as information medium and can use literally any transport medium, e.g. HTTP, E-Mail, JMS, etc. Using SOAP, the contract, which is the WSDL specification, between a service endpoint and a client is the interface description. The REST protocol can use any information medium, e.g. JSON, XML, YAML, etc., but is limited to the HTTP protocol as transport medium. Here, the HTTP methods like DELETE, GET, POST are the interface description.
You said, you're actually using AXIS2. If your experiences with that framework are good enough, I would recommend to use it further. CXF is simply another Web Service Framework which cannot be used together with Spring-WS (but it can be used with the Spring Framework). Here, I would consider that each framework has its caveats and needs some time to learn.
We have a test web application deployed In Weblogic 10.3.5. The web application contains a servlet which uses jax-ws to call a web service deployed in the same weblogic.
Accessing the servlet throws the following exception:
Two classes have the same XML type name "address". Use #XmlType.name and #XmlType.namespace to assign different names to them.
this problem is related to the following location:
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Address
at public com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Address com.sun.xml.ws.developer.MemberSubmissionEndpointReference.addr
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference
this problem is related to the following location:
at javax.xml.ws.wsaddressing.W3CEndpointReference$Address
at private javax.xml.ws.wsaddressing.W3CEndpointReference$Address javax.xml.ws.wsaddressing.W3CEndpointReference.address
at javax.xml.ws.wsaddressing.W3CEndpointReference
I copied the logic of the servlet into a common java class, and ran it. The test succeeded. So the problem should lie in the web application.
I have tried many ways, modify weblogic-application.xml to add prefer-application-packages section like below, but still doesn't work.
<prefer-application-packages>
<package-name>javax.xml.ws.*</package-name>
<package-name>javax.xml.bind.*</package-name>
<package-name>javax.jws.*</package-name>
<package-name>javax.namespace.xml.*</package-name>
<package-name>javax.xml.soap.*</package-name>
<package-name>org.apache.xerces.*</package-name>
<package-name>org.apache.commons.*</package-name>
<package-name>com.sun.xml.*</package-name>
</prefer-application-packages>
Anyone can help me on this, spent several days on this bug, no progress at all.
Thanks a million for your reply in advance.
Update 1
In the web application, we don't want to use metro, just use jax-ws downloaded from java.net, and put put jaxws-rt.jar, jaxws-api.jar, jaxb and other related jars in the ear/APP-INF/lib.
WebLogic Classloader Analysis Tool (wls-cat) tells there are some classes conflict, and suggests to add prefer-application-packages in weblogic-application.xml.
So We add prefer-application-packages to tell weblogic load them from from our application, not from weblogic jax-ws/metro implmentation.
But still doesn't work.
The problem might come from the fact that you want to use Metro JaxWs in Weblogic which has it's own implementation called Oracle JaxWS (based on Metro).
Here is a link where is explained how use Metro with Weblogic :
http://metro.java.net/guide/ch02.html#weblogic-10
If you don;t use Metro and rely on Oracle JaxWS you do not have to used preferred libs or any special packaging.
I have got a web application which is speparated in a GUI (JSF 2.0, Orchestra, Spring) and service (Spring, JPA, Hibernate,...) project. Due to network issues between the web server and the database server, I neet to split the application completely, between the layers and deploy them on two different tomcats, for the service part close to the database server. I have generated allready a webservice and a webservice-client with the Eclipse WTP CXF Plugin.
My Problem is: For the client it generates a copy of the domain model classes, so I can't use them directly in my gui project and would need to introduce an conversion layer, between the web service client and the gui layer. Wich is cumbersome and error prone.
Is there a possibility to generate the web service client (out of the existing web service module and the wsdl) using the shared domain model (model classes are in an separate project, wich both - service and gui - projects depend on)?
desperatly looking for a solution, as the deployment deadline is close...
To generate a copy of the domain model classes (DTOs) is a good practice when you have two physical layers : Your Hibernate POJOs need to be deproxyfied before being sent to an other physical layer. Maybe you could use Dozer to do it, to avoid to spend too much time doing it.
Maybe you should use RMI instead of Web Services if you need performances.
If you're absolutely determined to use your domain objects in the presentation layer, you should look about Gilead (formerly known as Hibernate4GWT).
Pure DTOs, DTOs with Dozer, and Gilead use are described in details here :
http://code.google.com/intl/fr/webtoolkit/articles/using_gwt_with_hibernate.html