[
Lists Home |
Date Index |
Thread Index
]
Thanks for your feedback - please see comments below marked with [JMC].
Joe
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
> -----Original Message-----
> From: Razvan MIHAIU [mailto:mihaiu@mihaiu.name]
> Sent: Tuesday, May 31, 2005 3:33 AM
> To: Chiusano Joseph
> Cc: Paul Downey; Rex Brooks; xml-dev@lists.xml.org; Michael Kay
> Subject: Re: [xml-dev] What are web services ?
>
> >
> >
> >Although no single, authoritative definition exists for
> basic terms like "service" and "Web Service", here are some
> fundamental characteristics that some folks believe that
> anything described as a "Web Service" should possess:
> >
> >(1) Can interact with it through the WWW;
> >
> >
> Yes, this seems to be one of the goals. I saw in many
> article praising web services that they can pass thru
> standard proxies+firewalls because they are based on HTTP
> (like SOAP is)
>
> >(2) Platform- and programming language-agnostic;
> >(3) Interface & invocation requirements are well-described;
> >
> >
> I can some up with some well-described (in my opinion)
> protocol but that doesn't mean that it is going to be a web
> service. Microsoft can some up tomorrow with some new
> protocol called "M-SUPER-C" that will meet the above
> constrains but that does not mean that this is a web service.
> So point 3 is only valid toghether with point 9.
[JMC] Yes - I should have stipulated that some of these points make the
most sense when joined with other points. Thank you.
>
> >(4) XML-encoded interaction mechanism;
> >
> >
> This is true according to W3C, but is this valid in the
> general sense ? Who says that a web service must be
> text-based and not binary ?
[JMC] No one does - I was speaking more from the standpoint of
standards-based interactions for greater interoperability (i.e. this one
may be also taken together with point #9).
> >(5) Payload most often is XML;
> >
> >
> "Most often" cannot be part of a definition.
[JMC] That depends on one's definition of definition. ;) I was
considering cases in which all or part of the payload may be binary, as
with attachments.
> >(6) Loose coupling between invoker and Web Service;
> >
> >
> You mean it must not have a state (like HTTP) ?
[JMC] State is actually a separate issue - the notion of coupling here
has to do with how much prior knowledge the invoker (service consumer)
and Web Service must have about each other in order to interact.
> >(7) Performs a specific, well-defined function;
> >
> >
> !!!? I am really tired of such high level super-generic
> definitions.
> What entity in the computing world isn't supposed to be
> specific and well-defined ?
[JMC] To clarify, the opposite of this would be a Web Service that
performed 20 different functions depending on the input it received (as
if it had a parameter that was a number between 1 and 20 that denoted
the function to be performed, and all remaining parameters would be
provided according to the function number). That type of Web Service
should probably be broken out into 20 different Web Services.
> >(8) May invoke other Web Services;
> >
> >
> Remote invocation is not big deal. How about a
> self-describing feature (WSDL) ? Can a "service" be called a
> "web service" if it doesn't have this feature ?
[JMC] That was the intent for #3 above.
> How about
> automatic discovery (UDDI) ? Is such a feature an integral
> part of a web service or is it just optional ?
[JMC] In order to be invoked, a Web Service needs to be discoverable by
its set of valid consumers (which may be one consumer). IOW, if it is
behind a firewall and a valid consumer cannot reach it, it is not
discoverable. Whether a registry such as UDDI is used to help facilitate
this is an implementation issue, as I believe registries are
cost-justified only when certain criteria are met (one being the
maintenance cost saved by implementing a registry outweighing its total
cost of ownership).
> Of course WSDL and UDDI are just implementations. You can
> replace those with ASDF and YRRT or whatever.
>
> >(9) Standards-based;
> >(10) Has the ability to perform its functionality synchronously or
> >asynchronously, as needed; (i.e. does not use synchronous
> interaction
> >when asynchronous is best, and vice-versa);
> >
> >
> Can you please explain what you mean by this ?
[JMC] Sure - if I perform a lookup on a flight/hotel/rental car site
(such as Expedia.com) for a flight given certain criteria that I have
input, that request should not be queued up with a number of other
requests by other users and handled asynchronously - it should be
handled synchronously (i.e. on a single processing thread). Likewise, if
I submit a purchase order that needs to ultimately generate an invoice,
I should not be left hanging on my screen for hours while the process
takes place synchronously instead of asynchronously. These same concepts
can be extended to Web Services.
> --
> Regards,
> Razvan
>
> SCJP preparation material:
>
> www.mihaiu.name/2004/sun_java_scjp_310_035/index.html
> www.mihaiu.name/2004/sun_java_scjp_310_035_test1/index.html
> www.mihaiu.name/2004/sun_java_scjp_310_035_test2/index.html
> www.mihaiu.name/2004/sun_java_scjp_310_035_test3/index.html
> www.mihaiu.name/2004/sun_java_scjp_310_035_test4/index.html
>
>
>
|
