aspose file tools*
The moose likes Web Services and the fly likes What's the deal with Web Services? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "What Watch "What New topic
Author

What's the deal with Web Services?

Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Hey people, not trying to be a troll or anything, but what's the deal with Web Services?

Since about the middle of last year (or possibly before) Web Services have been promoted as 'the next big thing'. I haven't looked into Web Services too extensively, but from what I've seen it's basically the idea that you 'componentize' parts of your application. These parts use XML based messages to talk to each other and there are various lookupsfor finding appropriate services.

I can see that this is really cool from a technological point of view, but I have a few questions about the business end of Web Services.

  • What incentive do businesses have for putting up free, reusable web services? What if you don't want it free? Can you charge someone using your service? What if you don't want it public... what if a competitor uses the information? What about 'leech' applications? I remember reading on slashdot about various airlines suing a website for using 'screen-scraping' to sell airline tickets. Can web services be protected in some way other than putting them on a secure LAN/WAN?
  • Another problem is the 'whole is greater than the sum of it's parts' problem. In the beginning, before there are lots of web services that lots of companies are going to provide, if you want to build an app, you're going to have to build each and every part. For example, to build an online book store, you'd have to write the book catalog service, a credit card charging service, a book rating service, etc. Why is a company going to 'componentize' their application. They're going to think, "I need to sell books", they aren't going to go to the trouble of making multiple reusable segments of their application.
  • Who's going to agree on all the interfaces these apps need to talk together? Is there some kind of built in way for Web Services to talk to each other generically, or do they have to agree on the interface? Are standards proposed (How?) or are they all just going to use de-facto standards (i.e. this was the first credit card charging web service to market, so all credit card web service interfaces now look like it to remain backward compatible.)


  • Just a few questions from a Web Services newbie!


    -Nate
    Write once, run anywhere, because there's nowhere to hide! - /. A.C.
    Lasse Koskela
    author
    Sheriff

    Joined: Jan 23, 2002
    Posts: 11962
        
        5

    What incentive do businesses have for putting up free, reusable web services? What if you don't want it free? Can you charge someone using your service? What if you don't want it public... what if a competitor uses the information? What about 'leech' applications? I remember reading on slashdot about various airlines suing a website for using 'screen-scraping' to sell airline tickets. Can web services be protected in some way other than putting them on a secure LAN/WAN?

    This is where the encryption and digital signature standards come into the picture. SAML, XML-Encryption, XML-Signature (and probably others) are trying to provide a standard way of providing integrity/non-repudiation/confidentiality/etc for businesses practicing commerce over web services.


    For example, to build an online book store, you'd have to write the book catalog service, a credit card charging service, a book rating service, etc.

    For example, validating credit card transactions may not be the book store's core competence (excuse the buzzword). That's why they are better off by using an existing solution, which happens to be a web service, from a trusted partner such as Visa. It's called outsourcing and has been going on for centuries...


    Who's going to agree on all the interfaces these apps need to talk together? Is there some kind of built in way for Web Services to talk to each other generically, or do they have to agree on the interface? Are standards proposed (How?) or are they all just going to use de-facto standards (i.e. this was the first credit card charging web service to market, so all credit card web service interfaces now look like it to remain backward compatible.)

    I agree that the common vocabulary is key to ubiquitous web services. However, there are movements such as RosettaNet trying to come up with a common vocabularies (messages) for specific vertical industries. On the other hand, web service orchestrating wanna-be standards such as BPEL4WS are aiming at a standard way of defining business processes. As to the "first-to-market, first-to-standard" question, no, I don't believe the industry will fall for that. As long as there will be at least two powerful players providing their proprietary interfaces, there will be a lot of pressure from the industry to merge them into a single standard.


    Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
     
    jQuery in Action, 2nd edition
     
    subject: What's the deal with Web Services?