I am new at webservice and i want to know where and when should webservices be used and exposed?
And what it takes to deploy and use webservices (wsdl file) on Tomcat or any other servers ?
Thanks.
From technology agnostic things the important knowledge is the stack composition: WS-(Servlet)-HTTP-(TLS)-TCP/IP (optional layers in parenthes). As a platform you typically try some lightweight option like Jetty or Winstone before falling back to the Apache Tomcal.
If you are after any webservice now, then a wise thing to do is just pick some mature Java standard technology like JAX-WS. There will be a good tutorial on java.net, respective Maven packaging and deployment plugins and IDE integration rigs. Once you have a simple thing working you'll have more specific questions most answered on SO.
Related
One of our product publishes a webservice using contract-last approach. This has becoming a real problem as all of our clients (ws clients) have to rebuild their client apps as soon as we release a new version of our product. This is due to all namespace changes that comes as a cost with auto-generated wsdls. We use Axis1 for javatowsdl. I've been seeking for a good methodology/ tool to develop backward compatible webservice for this.
i.e. version 9.3 clients can still hit the 10.0 service, of cause they will miss some of the functionality, that is fine. But they should be able to function without breaking.
I do understand the whole problem is due to our contract last approach (Pls. correct me if I'm wrong). Therefore, if the solution is to go for contract-first webservice what are the tools and technologies I could use? Also what are the best practises around contract-first?
Thanks in advance.
As you already realized, the recommendation is to use a Contract-First (or Top-Down) approach to develop Web Services. That implies a manual definition of your WSDL interface and generate a Java Skeleton of the Web Service based on this document using automatic tools.
Is important that your WSDL complies to the WS-I standart to assure interoperability between clients on different platforms. You can use SOAP-UI to test whether your WSDL is compatible with the standard or not.
For the Skeleton generation, there are several Web Service Runtime API's that you can use: Like Apache Axis and JAX-WS. I personally prefer JAX-WS because is a Java Standard and is supported by all Java EE Containers. Each container provides tools for the Skeleton generation, Weblogic has some nice Ant Task for that but there's also WS-Import that is Container neutral.
I am working on a Java EE project where there is a need to incorporate Web Services to transmit and receive data to/from external sources. I am not sure which way to go, Axis2 or JAX-WS.
Any suggestions will be appreciated.
The choice of a web services stack depends on what standards you actually need. Here are some stacks currently available:
The JAX-WS reference implementation is part of Java and provides basic support, including WS-Addressing, but not WS-ReliableMessaging or WS-Security. The big advantage is that you do not get additional dependencies by using the RI.
Another option is Axis2, which also provides support for these standards. As far as I know, the use of Axis2 is declining and personally, I found it rather hard to use (That's basically an opinion, I do not want to start a flame war).
I would suggest to consider a third option: CXF. It is another implementation of a web service stack and supports roughly the same as Axis2. I found it rather easy to set up and use and personally prefer it to Axis2.
One more option is Metro. Metro bundles the JAX-WS reference implementation and the Web Services Interoperability Technologies (WSIT). WSIT provides an implementation for several more standards and is tuned to provide interoperability with WCF.
Here is an article that compares these stacks with a little more detail. My suggestion would be: If you only need basic stuff (no reliable messaging, security, etc.) use the reference implementation. If you need support for additional standards, go for CXF or Metro.
Metro is the way to go! At lest for me :)
please see my comment in a similar question.
It depends on your requirement. What type of implementation you require.Java from its 1.6 version provides API for JAX-WS type of web service creation. But, really it's just for the basic requirement. If you want ws-Security,ws-policy etc. then please go for Axis2. Actually in Axis2 they have made lot of improvement from it's Axis 1.x version. The new STAX implementation is one of them. Apart from that Axis2 has made service creation part lot easier. Even, they support RESTful web services also.
Trying to find a way to rapidly develop web services on the Mac Server platform that will be served via Apache and need to be able to write to flat files or SQL Lite on the Mac.
We have .net, ObjC, C++, Python, and Java skills. We have done lots of web service work before on Windows and will probably go with Azure when we build out the product.
Our development server is on Mac OSX 10.5.8 and we are on a tight time and cost budget to get a prototype done for a small beta group (< than 500 transactions per day) that we can later rework.
We are thinking SOAP, possibly REST. Not sure what is available for Mac?
Any help appreciated // :)
If you are developing a service, you must have some idea what clients you are trying to serve. If those clients expect to talk to a SOAP service, you'll need SOAP. If you are just serving JavaScript code-in-a-browser, REST is probably sufficient.
Apache CXF, being 100% Open Source Java, can be used to build REST or SOAP services on MacOS or anywhere else. There are, of course, other options.
What about Ruby on Rails? Easy to deploy, runs great on the Mac - and is trivial to setup RESTful web services for.
If you dont need all the magic of Rails, the other (albeit) Ruby option would be to use Sinatra - I would challenge anyone to find a RESTful webservices library easier to use than that - its so elegant and so easy. I am primarilly a .Net developer, but I picked up Ruby and Sinatra in a heartbeat.
In either case, I would stay away from SOAP - In my opinion it's just too inflexible these days. In a web 2.0 world of live internet APIs making the webservices RESTful is the easier, faster (and smaller) option. We used to use SOAP exclusively where I work, but the reality is that it just doesnt deliever in the same way that REST does. With the accessibility of JSON and XML serialization frameworks out for any languge even the object passing is trivial. SOAP is harder to scale, is harder to test, uses more bandwidth and is not as flexible. Not everything can talk SOAP (out of the box), but tell me something that cant do a HTTP request?
I am a novice in web services. I am totally new to testing web services.
A new project demands that I test the web services, and the customer is in favor of any open source tool.
What is the approach to testing web services?
Also Please suggest a tool(with minimal scripting) to test web services?
Check out SoapUI - one of the best web service test tools - plus it's free!!
They also have a "Pro" version which costs - you can do more stuff, like load testing etc., but the free version is quite good enough for most of your testing, I'd say!
Given a WSDL (online or stored as file), it'll create stubs for each method, which you can then use to create requests (as XML), fill in the blanks (the parameter values), and then you can send off your request to the web service and see what comes back as a response.
SoapUI also allows you to write scripted tests than can be run over and over again.
Excellent tool - can't praise it enough!
Marc
Additionally you could use Firefox Poster in order to test your web service by passing XML-packets manually.
Check it here:
FF Poster
SoapUI is a great tool to test SOAP webservices. It allows you to test a SOAP client or a SOAP server.
Another very useful tool is Fiddler. Fiddler isn't necessarily aimed at testing webservices (it's a HTTP debugger), but since SOAP webservices run over HTTP, you can use it to testing. Another very important advantage of using Fiddler is the fact that you can test REST webservices also.
You might want to consider robot framework. It is a generic, keyword-driven testing framework. There are libraries for testing REST and SOAP based web services. It can also be used to test web pages (via a selenium library), databases, and a whole lot more.
robotframework has a ton of built-in keywords, and there are additional libraries that do much more. You are also able to develop your own keywords in python, java, .NET languages, or any other language.
We have a monolithic application written in Visual Dataflex, and various complementing applications written in other (.NET) languages. They all share the same database, and need to follow the same business logic. One way to facilitate unified business logic across these is to provide web services as an interface for testing.
Of course, for this to work, we need a good framework for testing web services. Any suggestions? For example, can Cucumber do this "out of the box"?
I'm assuming you're talking about Soap web services. You can use Soap4R to talk to a Soap web service. Wrapping this all up in Cucumber scenarios should work fine.
SoapUI is a pretty nice product for creating webservice tests, and they're easily callable via junit or just via the command line. It's also got some stuff for creating load tests as well.
They've got an opensource version as well as a professional version.