> Mark,
>
> It is your and Steve's definition with Heather's ideas. I just made the
> aggregation and the amendments. Kind of standing on the shoulders of giants
> (Haven't seen you folks f2f yet to see if you are really giants with broad
> shoulders :o))
8-)
> | - not sure what a "binding" is in this context
> | - don't know what "direct interactions" means
> <KS>
> My take on this is the definition of the "first contact" point Mike
> mentioned.
Oops, guess I missed that. As somebody else mentioned, we can refine
the definition over time. I'm not going to pick nits now.
> </KS>
> | - don't know what the significance of the distinction between
> | "application" and "component" is
> <KS>
> Yep. Like I pointed out earlier, to get the job done, the web service can
> invoke a component, just do it by itself or aggregate other web services or
> just sit tight. So component, application et al are kind of synonymous here.
> I am trading very lightly here, as we (as in Cisco) had months of passionate
> debate on services Vs components, still going strong.
> </KS>
Ok, fair enough.
I also wonder about the use of term "application programming interface".
As I see it, there are a lot of "interfaces" out there, and only some of
them are APIs. APIs are typically characterized by strong typing, plus
the use of programmatic types (arrays, structs, etc..), and other
features that herald from programming environments (typically involving
exposing in-memory representations for efficiency). While some of the
interfaces to Web services will be APIs (SOAP-RPC using the SOAP 1.2
encoding, for example), not all need be. For example, I wouldn't refer
to FTP or HTTP based Web services as being "API based".
Would just "interface" suffice? "machine processable interface" maybe?
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@planetfred.comhttp://www.markbaker.cahttp://www.planetfred.com