Knowlegde Through Fun Welcome To Mady's Site.

1. SERVICE HIJACKING (OR PIGGYBACKING)

Once your Web Service is available to the public, you may attract a
client who is particularly interested in the service you provide. They
're so interested, infact, that they consider wrapping your powerful
Web Service inside of their own and representing it as their own
product. Without security safeguards in place (and legal documents as
well), a client may repackage your Web Service as if it were their own
function, and there's no way for you to detect that this is being done
(though you may become suspicious by examining your usage log when
your client who occasionally uses your Web Service suddenly shows an
enormous increase in activity). Given the level of abstraction that
Web Services provide, it would also be nearly impossible for any
customers of your unethical client to know who owns the functionality.

Some organizations use a combination of usage logging or per-use
charges. Another simpler way to avoid piggybacking is by using false
data tests. We could create an undocumented function within our Web
Service that creates a result that only our logic could produce. We
would be able to determine whether this code is really ours and the
client is piggybacking our Web Service or if client is truly using its
own logic. For an example, we could say that the Web Service would
provide a specific result which is undocumented and known only to us.
Say , the Web Service is going to take as an input a phone number and
going to return the Name of the person / organization who owns the
phone number. Suppose we are sure that there is no entry for a phone
number containing only zeroes. So we make sure that when such a number
is entered the Service will return a message which is specific and
known only to us. We could then test this on the
piggybacking company we suspect is stealing our Web Service. Since this hidden

functionality would not be published, it would provide a great way to
prove that a company was reselling your Web Service's logic without
your legal approval.

2. PROVIDER SOLVENCY

Since the Web Service model is a viable solution, you're probably
eager to add their functionality to your core information systems and
mission critical applications. As Web Services become more and more
interdependent, it becomes increasingly necessary to research the
companies from where you consume Web Services. You'll want to be sure
that these providers appear to have what it takes to remain in
business. UDDI goes a long way towards helping you with this research
by providing company information for each registered Web Service
provider. In the business world, nothing seems to impact and force
sweeping changes more than insolvency, and if you find yourself in the
unfortunate circumstance of lost functionality due to a bankrupt Web
Service provider, you'll realize how painful the hurried search for a
new vendor can be (with little room to bargain with your ex-service's
competitors). Although the initial work can be a bit tedious, it is
important to know, as far as you can, whether a potential Web Service
vendor will still be in business five years from now.

3. THE INTERDEPENDENCY SCENARIO

The basis for all these and other Web Service considerations is the
issue of interdependency. The potential exists for you to wake up any
given morning, start an application that has worked for years, and
find that the Web Service that it relies on is no longer available.

To some extent, thanks to the UDDI search capabilities, you can
investigate and assess potential providers, but at the end of the day
a degree of faith needs to be put into the services of each provider
that you choose to consume.