Java Web Services

[lightng]

It's just another term to put on your CV.

Back in the days when marketing people were not allowed near software development we just passed strings about through sockets, now it's SOA or Web Services. Load of pish if you ask me.

If I may go into bible speak: "Theres nothing new under the sun".

... and no I'm not religious.

[NickFitz]

Web Services are generally used for inter-application communication.

For example, consider a web application that provides aggregated data about trading activity from a number of exchanges.

Each exchange would offer a URL that provided the required information using, let us say, SOAP. Our application would make HTTP requests to the several exchanges and combine that data. It would then make the aggregated data available in whatever representations it chose - perhaps as a web page, an RSS feed, and a SOAP endpoint that could itself be queried as a web service by other applications.

(The question of whether the application would gather all the data every time somebody requested one of these representations (meaning a lot of stuff flying over the net), or refresh a cache of the data independently of client requests, or any other possible approach is something to be considered in the context of your specific requirements. One other approach might be that the application also exposes URLs designed to have updates POSTed to them; the exchanges then push the changes to the application as and when they update their data.)

It's probably worth looking around in the W3C's Web Services area. Their recommendations (which is the term they use for "standards specifications") define the relevant protocols and so forth.

Also note that, while enterprises tend to go for massively over-engineered solutions using SOAP and WSDL and so forth, there is actually no difference whatsoever between what they are doing and what an amateur web developer achieves when "mashing up" data from (say) flickr, Upcoming, and Twitter for display on their blog, using more lightweight mechanisms such as JSON via REST APIs

[swamp]

Also note that, while enterprises tend to go for massively over-engineered solutions using SOAP and WSDL and so forth, there is actually no difference whatsoever between what they are doing and what an amateur web developer achieves when "mashing up" data from (say) flickr, Upcoming, and Twitter for display on their blog, using more lightweight mechanisms such as JSON via REST APIs

WHS.

Often easier just to have a cheap and cheerful Servlet and a query string. Web Services tend to be more complex document-based ones, so you need a .xsd schema as well as a WSDL. Right old faff, though needed if you're passing complex information from different platforms.

[bogeyman]

Also note that, while enterprises tend to go for massively over-engineered solutions using SOAP and WSDL and so forth, there is actually no difference whatsoever between what they are doing and what an amateur web developer achieves when "mashing up" data from (say) flickr, Upcoming, and Twitter for display on their blog, using more lightweight mechanisms such as JSON via REST APIs

But web services are 'discoverable' and self-describing. That's a big difference to mash-ups, surely Nick?

[lightng]

WHS.

Often easier just to have a cheap and cheerful Servlet and a query string. Web Services tend to be more complex document-based ones, so you need a .xsd schema as well as a WSDL. Right old faff, though needed if you're passing complex information from different platforms.

Depends on the tools. Developing Web Services in VS and .NET is p!$$ easy. Most of the work is done for you (and you still get to charge the client the same).

[NickFitz]

But web services are 'discoverable' and self-describing. That's a big difference to mash-ups, surely Nick?

There is that, although of course there's no reason why something like the flickr API couldn't be made self-describing using a lightweight format like JSON.

I'm not sure that most commercial usage of WS-* takes much advantage of those two aspects anyway - they tend to be tightly-coupled and to reflect some kind of business relationship, whereas those attributes seem to me to be intended to facilitate loose coupling, and to remove the need for any relationship between the provider and consumer of a service.

Good point, though.

[Durbs]

WHS.

Often easier just to have a cheap and cheerful Servlet and a query string. Web Services tend to be more complex document-based ones, so you need a .xsd schema as well as a WSDL. Right old faff, though needed if you're passing complex information from different platforms.

Totally agree with Lightng above, web services are simplicitely itself in .NET (too simple in fact). My granny could knock up even a complex web service in .NET.

Would assume they'd make it harder in Java though just for the sake of it.

[d000hg]

Totally agree with Lightng above, web services are simplicitely itself in .NET (too simple in fact). My granny could knock up even a complex web service in .NET.

Would assume they'd make it harder in Java though just for the sake of it.

Yeah doesn't Visual Studio have the ability for you to give it the URL of a remote web-service and it will automagically create all the classes you need?

Java does have some options for 'automatic' webservices. If you use EJB 3 then you get web-services for free, if I remember rightly, using the bean classes to generate WSDL and so on.

[Durbs]

Yeah doesn't Visual Studio have the ability for you to give it the URL of a remote web-service and it will automagically create all the classes you need?

Java does have some options for 'automatic' webservices. If you use EJB 3 then you get web-services for free, if I remember rightly, using the bean classes to generate WSDL and so on.

Yeah, just 'Add Web Reference', give it a name and bingo. Thats it.

[minestrone]

Most web services I have worked on are Java applications sending stuff to and from mainframes. The big financials are very resistant to moving business logic away from the crappy COBOL apps they have been building for decades.

What always happens is that they build their XSDs as the contract then the java developers go of and build their domain model from the XSDs using whatever XML binding tool they have chosen, castor, JAXB, apache beans etc.

The once procedural programmers are right in their element but as you are not allowed to change these generated objects you are just left with an anaemic domain model.

So when you want to work out if a user is allowed to make a contribution to a pension scheme for example an OO developer would put the canThisUserContribute( User user ) in the scheme object but as that is not allowed they just fire it into the controller class they are currently in. What you end up with is a business logic free for all with little steaming piles of turn all over your code. Worst thing is nobody sees this as wrong.