How can I interop easily between WCF and a Java app.?
WCF is a web service framework. Java also provides its own web service frameworks. They should be able to interoperate quite easily, although you'll need to ask a much more specific question if you want a better answer.
edit: The ProjectTango link you ask about says it all in the first paragraph:
... to ensure interoperability of
enterprise features, such as security,
reliable messaging, and atomic
transactions.
These are fancy additions to basic web services, and the specifications alone are not enough to ensure compatibility.
Basic web service interaction, which is all 99.9% of us ever need, will work just fine between WCF and Java.
Short Answer, Yes.
Long Answer, the interoperability depends on several factors. Basic interoperability is very easy. Only when you throw in factors such as security that things get complicated. We did some research on availabe Java web service frameworks and found out that the best suited one for our scenario is the metro stack along with netbeans 6.5 IDE. We achieved message secuity which has mandatory for the project using client/server mutual certificate authentication.
Some gotchas discovered in the process are:
- You have to add the webservices-rt.jar library from glassfish directory in netbeans project. (doesn't need glassfish to be running, just the jar file)
- WCF generates multifile WSDL files and netbeans cannot use them to generate proxy, although if netbeans is configured to use the URL (http://../?wsdl) it can generate the proxy.
- You have to put [IsRequired=true] on all datamembers in WCF. Java's handling of optional datamembers is quite complicated.
- Dictionaries as datamembers comes out as list
We have done this successfully on several projects. We use WCF basicHttpBinding, it is the simplest option if you just need to get it to work.
One of the things that can be a show stopper is if a service uses a platform specific datatype, like a Java vector or a .net dataset.
You can use JAX-WS services on the Java side, and then use WCF in .NET.
First create the JAX-WS services (glassfish libraries will allow you to do this). Create your POJO's, add the JAX-WS annotations, and deploy your WAR. Then, get the WSDL generated by your server and give it to VisualStudio. VisualStudio can generate the client for you.
That is the simple way, but your mileage will vary of course.
Related
I like Play 2.0 much (especially Scala API). But it lacks SOAP completely. Is there some not mindblowing way to provide SOAP WS (wsdl based) from Play 2.0?
Say, I'd want it to be accessible from some URL (e.g. /soap), preserving other pages to be HTML. Please, help, I have no clue (I'm java newb, and zillions of abbreviations for frameworks and libs make me confused).
PS To prevent possible unproductive treatments: I'm a java newb but not a newcomer programmer, so I know how SOAP, HTTP and other stuff are meant to work at protocol level.
I ran into the same problem - Apache CXF and Axis2 depend on the Servlet API, which the Play Framework doesn't have.
I created a custom transport plugin for Apache CXF which connects to Play's Controller API.
There is a tutorial about setting it all up in an empty project: http://www.imind.eu/web/2013/11/07/developing-soap-services-using-play-framework-2-2-x/
The plugin's source (and a sample Play application) is here: https://github.com/imindeu/play-cxf
If you trying to create a web service API for existing business logic that will be part of your Play service, then you should probably look using existing Java libraries that can do the SOAP magic for you (e.g. Axis2). Scala can use existing Java libraries without any problem.
However, most people would strongly recommend you look at a REST service rather than a SOAP service, if this is an option. Have a look at Play Mini to see how this is done.
UPDATE:
Ah, this may help you: https://github.com/mandubian/scala-xmlsoap-ersatz
I need to write a web service client in Groovy. The author of the web service has proposed various unappealing blobs of Java code that I could use to call the service from my Grails application.
At this point, I think it might be better if I just ask them to give me the WSDL and I'll take care of the client code myself. I'm looking for suggestions about the best way to go about writing a Groovy web service client using only a WSDL document?
I expect most suggestions will involve using some tool to generate a client-side API that I'll call from my Grails app. If so, then it's important that I can integrate generation of this API into a Grails build, because the WSDL document will probably change frequently.
I've looked at using GroovyWS which provides a very simple way of calling web services. However, it seems to lack any concept of a contract which concerns me from the point-of-view of testing. I would like to define a contract (interface) for the web service, for which I provide a real implementation that the app will use and a mock implementation that my unit tests will use.
Given your desire for more stability than the very dynamic GroovyWS, I'd suggest the easy way:
Use JAX-WS to generate a Java client, compile that and use it from Groovy. It's all statically typed and the generate Java source is reasonably clean (definitely much better than older WS client frameworks such as Axis 1).
Of course that would require that you have access to the WSDL.
Is AXIS or CXF necessary for Java web services? Can it be all done via the JDK (1.6)?
Is AXIS or CXF necessary for Java web services?
No. Although Axis2 is the most popular framework to work with Web Services is not the only way to do them.
Can it be all done via the JDK (1.6)?
Yes, but it is way much harder. You will benefit tremendously from using a framework used by others apps and from the bug fixes the development team provide. Doing all by hand is like reinventing the wheel.
If you want to have full control of what's happening underneath, probably you could go with: JAX-WS
or if the application is very simple, directly with socket.
But again, Axis2 is the canonical way to do WS ( but not the only one )
The following is based on an all to true and personal story:
So you want to consume a web service in your Java web application, and you don't want to add 10MiB of JARs to your lean 1.3 MiB .war file, and besides you are great at parsing XML (you can hand code XPath Queries, and XSLT files), you totally understand HTTP, and the client you are interfacing with has great documentation. You download the WSDL look at your endpoints and your methods and start creating a Java class that maps to the features you are going to need. You feel great already.
They you start reading up on how to send a SOAP request and you think well this looks a little verbose but what they hey it's all just a string, so you start building a utility that takes your Java request object and converts it to a SOAP request. You send your clear SOAP request to the server but it gets denied (missing a signature).
So now you start adding encryption JARs to your project and you start looking at how to calculate a signature of part of an XML document and include both it and the document in the request. This takes you a while but with enough hacking you get a message that you can send to your soap service and you are now dealing with the SOAP response. Now you are feeling great...
Until the admin at your client changes their security requirements, issues new public keys, and updates the soap interface with some custom types, and your next client who is running a similar service (but on a Windows Server) wants you to implement with them as well.
At this point I gave up trying to implement this in a pure Java way and just started using standard libraries. They deal with stuff like encryption, marshaling, deviations form the standards and they let you focus on stuff that is closer to your problem domain. I hope you can save yourself the lost month it took me to learn this lesson.
An update on the landscape of web services in 2013.
Web services used to be SOAP and XML-based. Web services were standardized into JAX-WS. Some of the more popular frameworks are (were):
Axis 1.x
Axis 2
Apache CXF - CXF also includes other protocols. It is a much broader framework
Metro Web Services which includes the JAX-WS Reference Implementation.
Java 6 and Java 7 include the JAX-WS RI by default. It means that frameworks are no longer needed except to generate client and service stubs / skeletons
There are other implementations not listed here that are vendor-specific e.g. IBM Websphere's WS implementation and Weblogic's WS implementation.
Generally though, to create web services, I would recommend Metro and the JAX-WS RI.
Note that there are many WS-* standards e.g. WS-Security which may not be part of all WS implementations.
Since web services have been around for a while, other alternatives have come up both in terms of architectural style, protocol, and encoding.
For instance, XML used to be the de-facto encoding. JSON is now more prevalent. It is worth looking into Jackson, a JSON parser, or Google GSON. The main arguments in favor of JSON are that it is easy to use, lightweight, and developer-friendly.
Along with JSON came REST. REST is an architectural style. With REST, you can still implement "web services" in the sense of remote services that can be easily consumed over a network. REST has also been standardized in the Java family of standards as JAX-RS. Some of the popular JAX-RS implementations include CXF, Jersey, and RESTLet.
Finally, there are some new kids on the block that use binary encodings. Those are Google Protocol Buffers and Apache Thrift. Their main goal is performance as well as broader support for other languages (Java, C#, Erland, Perl...).
When developing a web service today, the question should be:
- do I care about performance?
- do I want to access the service from many different languages?
- do I want mobile-friendly?
These should help you guide your choice. Also, I prefer to keep my dependencies to a minimum. This means I would rather take something that is native to the JRE or JDK e.g. the JAX-WS or JAX-RS reference implementation.
As an alternative to Axis, you can use the Spring WebServices framework to run your webservices application within a J2EE container like Tomcat or anything similar. I've found it very easy to use and setup, and if you want to integrate your webservices into another web application later, it's quite easy to do (I've done so myself on two separate occasions).
You can use the http streams provided by the webserver as you whish, but using a framework and some jars (which are proven to work) will save you a lot of headaches and a lot of time in the long run.
Normally you will want to use a programming framework for web services.
Something like AXIS, CXF, or the Java EE (GlassFish) download from Sun.
We are building a web-application and a significant portion of the project will be making real time calls from our servlets to some back end webservices. Some of these calls will be cached depending on the context. We will also have a reqiurement to handle incoming double byte character strings for languages such as Hebrew and CJK.
The platform this web application is in is Java.
What types of frameworks should i use for consuming and calling these web services? Axis 1/2? Does an ESB such as Mule give me some added features that will come in handy?
Clarification point: We will only be consuming webservices. We will not write and provide our own webservices.
Axis2 will work fine but I'd also consider Spring-WS. If this is a basic web service and you don't anticipate alot of consumers then I would shy away from ESBs and such (ESBs are great if you need them but don't force them if you don't need them).
I'd also suggest that you take a look at Apache CXF as well as Apache Axis2.
If you use Java 6 it has built-in support. I use IntelliJ to generate the needed classes from the WSDL (which in turn calls wsimport) - a recent client shipped in a 26 kb jar.
For your requirements an Web service implementation like Axis 2 should be good enough. Also there are other implementations like Spring web services too. Unless you need some serious service orchestration and service mash ups, an ESB will probably be an overkill.
Axis2 is good. You can deploy the WS and then, use the Eclipse wizard to generate the client.
Currently I am evaluating number of web service frameworks in Java. I need web service framework that will help me to expose some functionality of existent application running on JBoss, The application is mostly developed using Spring and POJOs (no EJBs).
What I need is a framework having following properties:
It should provide tools for automatic generation of boilerplate code and save time by eliminating repetitive tasks, for example tools generating WSDL from Java (java2wsdl), tools generating endpoints etc.
Applications should be easily deployed on existent J2EE platform (JBoss), this means that it should contain as less as possible configuration files (like axis2.xml in axis2 framework).
Also it is preferred to be able to deploy web service within .war archive of existent application. (it seems that Axis2 need a separate archive for web service app.)
It will be very cool to use a combination of POJOs and Spring.
Generally, the framework should have clean structure and design (for example Spring-WS lacks it), good documentation and whatever else characterizes a good piece of software.
It is preferred that framework incorporates some standard features like JAX-WS etc. instead of vendor specific methods.
I have briefly examined
Axis2
Apache CXF
and Sun's Metro
Spring WS
But still it is difficult to decide what to use in my case:
Axis2 seems to be so low level, it requires separate application archive and lots of configurations
Spring WS seems to be too opaque and "sophisticated for impression purposes (?)"
Apache CXF and Metro probably are two frameworks that I prefer to chose from but still
I need your opinion and experience about usage of some of them in a real-world applications.
I've used CXF's forerunner, XFire, for a while now and it's not been too bad. At the time, we migrated from Axis for two major reasons: performance and ease of development. At the time (don't know if this is true now), the performance of XFire was much better than anything out there, and with annotation-driven development, instead of having to run stub generation, it was really really easy to add new web services.
CXF seems to be more of the same but better - we haven't migrated yet due to constraints on development time as well as not having a pressing reason to do so (plus the relative lack of documentation 6-12 months ago wasn't too encouraging). Additionally I haven't really evaluated the market of late, so I can't tell you how CXF stands up to its contemporary competitors.
Regarding your points:
There is no boilerplate code to be generated, the WSDL is automatically created from the service class' annotations and published by the server.
Deployment in Tomcat was relatively simple. Just define another servlet in web.xml and map a URL pattern to this servlet.
Our web services were deployed in WAR files, I'm not sure what the alternatives are in fact but this seemed to be the default and obvious way to do it.
POJOs work fine initially; we've now moved most of the web service object creation to Spring in order to wire more complex conditional dependencies in and have had no problems with this.
Documentation was a weak point with CXF originally, though having just had a look it seems to be better now. The general design and architecture seems relatively sane; slotting in one's own filters to modify the transmission details was not very painful, and extending existing classes has generally been considered (so sensible methods are marked protected instead of private, for example).
JAX-WS is full supported in CXF.
So I'm probably a little impartial as I haven't tried the other ones, but I'll give a thumbs up to having a look at CXF. It's pretty fast, relatively simple to get going with and fairly powerful if you need to tweak it.
We have tried Metro and CXF and kept CXF because Metro includes too many dependencies like Sun's APIs in its jar files which makes it difficult to integrate in another application server than Glassfish. CXF has a cleaner packaging with explicit external dependencies.
We also failed to enable Gzip compression with Metro while it worked like a charm with CXF.
I'd go with Spring WS first and XFire second. I'm a Spring user, so I'm used to the opacity.
XFire now Apache CXF was far away easier to use than Axis. I had something done very quickly using it where Axis seemed overly complicated. I didn't look at Spring WS.
I will use CXF. It is easy to use than Axis2
I have only used the Spring WS because that is what I was told to use, but it was a pretty easy use framework. If you have to go with soemthing else I would go with XFire due to the JAX-WS support.