I have done this on Websphere (re: title of this topic) using wsdl2java for generating wsdl to java mapping xml file.
My endpoint is a generic stateless EJB. The code in EJB is generated by traversing the each wsdl and getting the wsdl operation and stuck it in the generated remote EJB interface.
Each EJB method impl is generic and handles all the services the same.
Used instructions on this doc to do this on WAS: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/twbs_devwbsjaxrpcwsdl.html
Now, I am asking you all for help if anyone has done something similar in Sun AS 9.1.
Starting from existing WSDL (and xsd) files. Knowing the sole EJB service endpoint implementation for each services are the same, and generating an EAR file (webservices.xml, ejb-jar.xml, etc).
Have struggled with wscompile and alike, but not getting anyware in the same fashion I did for WebSphere.
Thanks for help.
You want to create a WS client which runs under Sun AS? I don't know Sun AS in detail and I don't know the WS libraries it supplies. But you may want to use a public WS library:
Apache Axis 2
Apache CXF
For every library there is documentation which describes how to create a project from WSDL.
You could even use Eclipse to create a project from WSDL for you: File -> New -> Other... -> Web Services -> WSDL. Make sure you have the "WST Web Services" Plugins installed.
I've never used it myself, but I just recently read about the wsdlLocation() attribute of the WebService annotation, which is supposed to map the service to a preexisting WSDL document (not sure if you're even using EJB3, though).
Related
I'm consuming a webservice where the WSDL file contains imports to other wsdl and xsd schemas, e.g:
<import namespace="http://my.api.com/" location="http://other.server.com:8888/context/services/MyService?wsdl=1"/>
which in turn can import other files
<xsd:import namespace="http://my.api.com/" schemaLocation="http://other.server.com:8888/context/services/MyService?xsd=1"/>
The client is generated by cxf with a maven plugin. The main WSDL file is added as a classpath resource. However, at runtime it appears that the client actually needs access to other.server.com:8888 to resolve the WSDL completely. So the question is, does a tool exist for importing and resolving all URLs in a WSDL so that it is not dependent absolute server URLs in other imports in the WSDL, and suitable for including in a client project?
We do not control the WSDL, so we can't change it in the source.
Edit: Looking for a tool that works on Linux
Check the ServiceModel Metadata Utility Tool (Svcutil.exe) from Windows SDK.
svcutil /t:metadata http://service/metadataEndpoint
This tool locates or discovers, one or more related documents that describe a particular XML Web service using the Web Services Description Language (WSDL).
I don't know if I understood your question correctly. I'm having my battles with Jax-ws/SOAP too. :)
If you need to generate the java classes needed to call the webservice you can use Apache CXF. Inside it you have a wsdl2java. You can use it on linux.
Another option in Java SDK, on the bin folder there's the wsimport that you can use it too.
Edit: You can change the final URL at runtime using the Service class created by Apache CXF.
new SomeRandomJaxWSService(new URL(wsdl),new QName(namespace, serviceName))
When I create a new Web service using RSA 7.5 IDE and Web Sphere 7.0 server from a Web Application, then I can see a few auto-generated files created by this process, namely:
1) For the service, a SEI file is created
2) For the models, ser, deser and helper files are created.
But I cant understand what are the use of all these SEI, ser, deser and helper files.
Any valid explanation on this will be much appreciated.
BOUNTY EDIT:
Bounty-Edit:
Since I did not get any response I would like to ask this question again - offering a bounty to encourage an in-depth answer. I would love to know how and when are these files used internally?
Regards,
Service Endpoint Interface (SEI):
SEI is the Java interface corresponding to the Web service port type
being implemented. It is defined by the JAX-RPC, which specifies the
language mapping from WSDL 1.1 to Java. Ref
Or
A service endpoint interface (SEI) is a Java interface that
declares the methods that a client can invoke on the service. Ref
These ser,dser,helper are helpers to convert an XML document into a java object and vice versa (WebServices). Ref
Files generated in the server project: (WebSphere Application Server 6.1 Ref)
According to the settings made during the run of the wizard, the following files in the WeatherJavaBeanWeb project have been created:
Service endpoint interface (SEI): itso.bean.WeatherJavaBean_SEI.java is the interface defining the methods exposed in the Web service.
WSDL file: /WebContent/WEB-INF/wsdl/WeatherJavaBean.wsdl describes the Web service.
Deployment descriptor: webservices.xml, ibm-webservices-ext.xml and ibm-webservices-bnd.xml. These files describe the Web service according to the Web services for J2EE style (JSR 109). The JAX-RPC mapping is described in the WeatherJavaBean_mapping.xml file.
Data mapping files: The helper beans in the itso.objects package perform the data conversion from XML to Java objects and back.
A servlet is defined in the Web deployment descriptor to invoke the JavaBean.
Hope this information help you.
Those files are related to the WebSphere mapping between Java, WSDL, and XML. They are automatically generated, and should not need to be edited. You should pretend they are not there (except if they are not there you may have trouble deploying...).
SEI - Service Endpoint Interface
ser - Serialize
deser - Deserialize
helper - ?
Here are some psuedo-helpful links, that may provide some more insight into your question:
IBM Technotes
WebSphere v6.1 Handbook (check Chapter 15 -> Creating a Web Service --> Generated Files)
All these files are basically generated for webservice.
A web service ia basically a port between 2 running applications independant of the framework or language.
Leta say if you are using java from one side of web service then for complete compilation the java end would need some class files that have those methids which you wish to call on the service.
For this a stub is generated. This stub is basically an interface(SEI).
Also websphere needs additional files for implementing the webservices functionality, thus tge helper files.
This is basically the summary of it.
I'm working on a web-service-proxy with auditing (later on with caching = creating own responses) and I need to generate #Endpoints (such that will just forward i.e. call a remote web service or dummy atleast). Marshaling/unmarshaling seems neccessary for the proxy will add "something" to the request...
We are to use spring-ws and JAXB. Got all XSDs and static WSDLs of the proxied web service.
Any hints around? Anyone doing something similar? How are you doing it?
Is there a simple way how to achieve this using spring or spring-integration?
Thanks in advance..
This should be possible using both Spring WS and Spring Integration:
With Spring WS, you can create a proxy class for your remote WS, wrapping around a org.springframework.ws.client.core.WebServiceTemplate to talk to the WS - which has API's to take care of marshalling the request to xml and unmarshalling the response.
With Spring Integration, you can use an outbound Webservices gateway , but you will need to front it with a messaging gateway, which will act as your proxy, along these lines:
<int:gateway id="wsproxy" service-interface="..ProxyInterface" default-request-channel="requestChannel" default-reply-channel="replyChannel"/>
<int-ws:outbound-gateway id="wsGateway" request-channel="requestChannel" uri="http://serviceURL" marshaller="someMarshaller" unmarshaller="someUnmarshaller"/>
However, I would recommend the first approach of using the WebserviceTemplate, as you do not have a very complex integration need here.
Today I can tell how we proceeded without spring-integration. We found two different ways how to generate #Endpoint class.
1) Using XSLT and Freemarker we generated the endpoint class source in pre-compile phase. XSLT transformation walked thru all WSDL files to create one summary file which was then used to generate the source.
2) Using Javassist we copied the template class, then generated methods regarding content of JAXB2Marshaller instance and finally instantiated object using FactoryBean, all at server start-up.
Problem here we met was set of XSD files written in form that caused the root objects were generated without #XmlRootAnnotation. Javassist version we had internally works with Java 1.4 (no generics) so we used global customization file for XJC and forced #XmlRootAnnotation on root objects.
Both solutions have their pros and cons but both are simpler then using ESB.
Greetings everyone,
Prior to my specific question, I'd like to mention that I am not looking for a step by step solution but for a possible YES or NO whether or not I will be able to achieve my goal with what I'm planning.
What I've got:
A wsdl that was autogenerated by Axis 1.3 an that is RPC/encoded. - I dont have any influence on the Webservice per se.
What I try to achieve:
Generating a Spring WS Client from that wsdl.
What I "know":
RPC/encoded WSDLs are deprecated and not "supported" by Spring WS
Spring WS can deliver any valid XML
I have to get the schema from the WSDL - > .xsd
I'm doomed.
What I'm not sure of:
is the .xsd enough or do I need to generate/write an .xjb to generate the Classes?
The Question:
Is it possible for me to get the .xsd from the RPC/encoded WSDL and generate my Java Classes for the Spring WS Client without too much "hacking around"? Or should I just go along with developing cruel Axis 1.3 generated Classes with all their miseries?
Thank you in advance.
If you don't like Axis 1.3, JAX-RPC is a slightly easier to use alternative.
I'm trying to expose a web service method via JAX-WS annotations. Many examples I've seen reference the EndPoint.publish() method to quickly stand up the service in a standalone app (ex from Java Web Services: Up and Running, 1st Edition):
public class TimeServerPublisher {
public static void main(String[ ] args) {
// 1st argument is the publication URL
// 2nd argument is an SIB instance
Endpoint.publish("http://127.0.0.1:9876/ts", new TimeServerImpl());
}
}
One thing that I'm missing is how to accomplish essentially the same thing but in an existing app. Would I make a servlet to handle this? What is the proper way to publish this service in an existing WAR file?
In a container you don't have to publish like this. The container will do the publish. If you plan to use it in JBoss server try JBossWS otherwise for Tomcat or any other server Axis2 may be the better choice.
Read more from the following links.
http://jbossws.jboss.org/mediawiki/index.php?title=JBossWS
http://ws.apache.org/axis2/
This depends on what WS stack you are using.
If you are using Java 6 then that includes the JAX-WS reference implementation, then you can consult the documentation about JAX-WS RI WAR contents.
As #Jerrish and #andri coments, there are different aproaches and solutions, depending on your concerns.
The idea behind is that you don't need to set the configuration (port, etc) when will be published your web service. The best approach could be to set this via configuration files (XML, properties, etc) or using #Annotations.
For example, if you're accustomed to use frameworks like Guice or Spring, you know that is possible/recommended to start the context of your application publishing or initializing some objects, factories, datasources, etc and publishing webservices is another task that can be done in this time, because will be available when you will start your application, isn't?.
By the way, I've good experiences with CXF and another solution could be Spring Web Services another powerful solution for creating web services.