RE: Feedback on Web Services (RE: Web Services stuff - fyi)

[Manoj Dhooria <manojd@geometricsoftware.com>]

Yes to #1 & #3 here at Geometric. We have built a substantial system over
HTTP/XML for certain engineering applications. My experience:
a) Actual remote "API call" mechanism is probably 1% of total effort needed
to build your application.
b) For any non-trivial application, you will probably need application
specific caching & "fine granularity" APIs at application programmer level.
Actual remote API calls ("a" above) must necessarily be of coarse
granularity, or you will have an unusable system.
c) It will be useful if the there were a generic mechanism that all
applications could use for coarse granularity calls of "a". It could be SOAP
based, or something else. Unfortunately, the best you are likely to get is
"techniques" to implement your application-specific remoting system. Within
an application domain, there can be a possibility of common standard for
this. When my application area does not have such a widely deployed
standard, I am likely to end up inventing my own scheme (probably using
public "techniques"). Which is what I did - built my own "propietary"
application-specific API remoting system over HTTP/XML.

Manoj Dhooria
Geometric Software
Bombay

-----Original Message-----
From: Amit Bhatiani [mailto:amit@invertica.com]
Sent: Tuesday, June 05, 2001 7:02 AM
To: Michael Brennan; 'Edd Dumbill'; xml-dev@lists.xml.org
Subject: RE: Feedback on Web Services (RE: Web Services stuff - fyi)


Could not agree more on the general hype surrounding web services. Here are
more specific questions to Michael, Edd and the group in general that might
elicit more specific answers.


1. Has anyone implemented a SOAP based RPC or otherwise synchronous callable
style interface in production?
2. Has anyone implemented a UDDI registry that contains something more than
toy entries?
3. Has anyone thought about stateful XML-based services?
4. Has anyone thought about transaction semantic across XML based
connections over HTTP?
5. What do "Web Services" mean for EAI type solutions?
6. What do "Web Services" mean for message brokers (like MQSi)?

I have more burning questions, but these seem loaded enough for now.

--amit
-----Original Message-----
From: Michael Brennan [mailto:Michael_Brennan@allegis.com]
Sent: Monday, June 04, 2001 8:19 PM
To: 'Edd Dumbill'; xml-dev@lists.xml.org
Subject: Feedback on Web Services (RE: Web Services stuff - fyi)


Certainly the hype syndrome for web services has been great, but no more so
than that for XML itself, IMO. I think the hype surrounding XML in general
has been far greater -- and all too often, much farther removed from
reality. We've passed the peak of the hype curve with XML, though, and see
less of the most outlandish claims these days, while we still have a ways to
go before we hit the peak of the Web Services hype curve.

We have strong interest in Web Services here at Allegis. We have for some
time supported an integration API based entirely upon XML over HTTP. We also
use XML fairly extensively for other purposes, as well, though most of the
IT staff at customer/partner organizations who must use our integration APIs
don't. Typically, they are XML novices, and we have to provide considerable
guidance on not simply our own integration APIs, but basics on how to deal
with XML APIs (DOM, SAX) and how to properly transmit XML over HTTP
(something which there is a scarcity of good technical info on, and which
the overwhelming majority of developers don't know how to do correctly).
Developers who are not already steeped in XML or similar markup languages
tend to find working with XML to be an unnatural and unfamiliar model. They
also tend to trip over issues such as character encoding; very few
developers understand character encoding issues, and how to deal with them
properly when transmitting XML over HTTP.

One of our solutions to this challenge was to write our own Java-based
toolkit for dealing with our integration API. Part of that is just utility
classes that transparently deal with the HTTP protocol specifics and
character encoding when sending XML. Part of it was to introduce a
data-binding scheme that enabled the Java developer to deal with a more
familiar paradigm -- setting properties and invoking methods on Java objects
-- rather than having to learn XML APIs.

Web Services will let us go further down this latter road, while leveraging
more third party tools. The metadata standards that are part of Web Services
are a great facilitator to data-binding and code-generation techniques that
mask the XML and protocol specifics beneath more familiar programming
language constructs -- in the same way that EJB masks the specifics of
CORBA/RMI/whatever and lets the programmer focus more on business logic. In
addition, the RPC mechanisms such as SOAP-RPC can similarly let developers
work with a more familiar paradigm even without relying upon the additional
metadata for code generation or data-binding. However, our core integration
APIs will still be XML-based, so those who are more comfortable dealing with
the API at that level will still be able to do so.

> -----Original Message-----
> From: Edd Dumbill [mailto:edd@usefulinc.com]
> Sent: Wednesday, May 30, 2001 3:58 PM
> To: xml-dev@lists.xml.org
> Subject: Re: Web Services stuff - fyi
>
>
> On Wed, May 30, 2001 at 12:12:13PM -0700, Jeffrey I Condon wrote:
> > Here's some stuff from developerWorks and alphaWorks if you'r
> > interested in Web Services.
>
> I'd love to get some feedback on who actually on this list is
> interested
> in (and/or deploying) web services, and what aspects of them you find
> interesting/useful.
>
> I've been in the skeptical camp for a while (largely due to
> overwhelming
> hype syndrome), but I'm very curious as to the scenarios this stuff is
> being deployed in -- and furthermore, if deployers of web services use
> XML in any other capacity, or pretty much stick to the protocol stuff.
>
> -- Edd