Quote:>how do i recognise a webservice ??
It's a service you get at over the web.
But to be useful, it must also be "a webservice built out of
commonplace protocols", so that it's easy for other groups to build
clients for it. It's not essential to be open in all cases, but it is
for many and it's useful for all of them.
Web services (broadly) have been around since the early '90s, but
weren't any use. You took protocols like CORBA, DCOM or RPC and ran
them over lashed-up session layers built on IP. Every site did it
their own way, and nothing would inter-communicate.
The gimmick now is that there are a handful of common protocols (SOAP
- also .NET, XML-RPC and some older ones based on HTTP). These
protocols are easily understood by all competent developers, because
they're a simple addition to a well-known pre-existing protocol, like
TCP/IP, UDP, HTTP etc.
If you ask, "What is a web service ?", then it would have to be a
paper definiton of a protocol for people to write them.
Quote:> if i go to a web site and the
>information i put into some fields are sent to a database? is that
>database itself a webservice?
A database should never be a web service. Build your web service as a
service that's _application_ oriented, offering some useful service to
your customers, at a level of description and abstraction that they
can understand. Sell them "Store your birthday reminders list on our
site and have your PDA sync automatically", not "create a table in our
database and query it".
A web service that exposes the raw database has two faults; it's not
robust against switching to a new database to run the old service on,
and it's also not secure again the all-too-common database attacks (go
to The Register and search for "SQL Injection Attack")
Quote:>can a stand alone application such as microsoft word be a webservice
Could be - but Word is a little unusual, because it contains a
powerful programming language and the ability to conect to ActiveX
controls. With the XMLHTTP object of the MSXML control (M$oft's XML
control for everything) then you can write SOAP clients in JScript or
This isn't a good approach though - too complex. And when programmers
have to do complex things, they get it wrong.
A better approach is to use a SOAP control (I've no idea if such a
thing exists). This would build the SOAP layer into the control and
give a higher-level interface (thus simpler to use) to the JScript /
In the world of Java middleware (WebSphere, WebLogic etc.) it;s even
easier. You find a web service that offers an automatic description
via WSDL, and it build your code for you. Or else you show it the code
for your service, and it builds the WSDL for you.
Quote:>if i want to build a website that can collect information from
>interested clients and save them to a database..........how will i
>access my databse as the owner of the service,
However you damn well please. This simply doesn't matter - your
clients will use another route.
Quote:>how would i retrieve the stored information?
Simplest explanation article I saw on this (on SOAP) was a demo client
written in IE 5 JScript by Aaron Skonnard a few years back. It was
absolutely minimal, but it showed what just a DHTML page in a browser
could achieve or could connect to.