RE: WSA constraints

Mark,

Software conforms to an architecture, not the other way around.

We're defining an architecture for the future. We don't need to rely on what
people have implemented today. If we always designed architecture based on
existing systems, we'd never innovate. We harvest from existing systems to
understand how people have done stuff in the past -- to identify what works
well and what causes problems. But that's not the end of the road. Next we
need to figure out how to correct those problems without damaging what works
well. People tend to use code to help them develop improvements in the
architecture -- it's the iterative process. But it's definitely not the
"primary" place to "find" the architecture. (Do you "find" architecture?)

The primary place to start when designing an architecture is with your
functional requirements. That's why this group started its effort by
defining requirements. What are we trying to accomplish? What are the basic
needs that we have to address? How have people tried to solve the problem
before? What problems did they have trouble solving? What other paradigms
have had to address these types of problems before? How did they solve these
problems? How can we use their techniques in our system?

This way of thinking is the whole reason that Web services came to light.
(At least from my SOA perspective.) People have been trying to do
application-to-application communication for years. We'd solved a lot of the
really gnarly problems in a corporate environment using CORBA and DCOM,
although we still hadn't managed to solve the language- and platform-neutral
issue, or the pervasiveness issue. And scalability was still giving us some
trouble (SOA systems have always used inefficient naming services that tend
to be tied to a specific machine, and they dynamically allocate
communication ports).

Then along came the Web. The Web solve a number of problems that have been a
thorn in the side of SOA since the beginning. Web protocols are pervasive.
DNS scales. But the Web has been a human-focused technology, not an
application-focused technology. It's not immediately obvious how to exploit
the Web in an SOA scenario. At first the SOA folks tried simply to make
their stuff run over the Web, but dynamic ports don't work through
firewalls, and the naming services are too focused on *this machine*. There
are serious incompatibilities between traditional SOA and the Web, but the
SOA folks weren't quite ready to reinvent SOA based on the Web. Instead they
tried to fit a square peg in a round hole. They tunneled CORBA, DCOM, RMI,
etc through HTTP. In some cases that tried to develop firewalls that could
deal with constantly changing port numbers. Anyway you look at it, it's all
a terrible kludge. Thinking back -- I think it's amazing that no one tried
to build a Web-centric SOA system circa 1996. I guess that scalability and
pervasiveness just weren't strong enough incentives.

Then along can XML. Wow! XML totally solves the language- and platform
neutral problem. And it so easy to incorporate this technology in the SOA
architecture. Obviously this problem was much more pressing, because this
provided the incentive to be innovative. Almost overnight someone started
building an XML-based RPC system, and soon afterward, Web services were
born. But both you and I agree that XML-based RPCs abuse the Web. More to
the point, they don't exploit the power of the Web. They don't help the Web
achieve its full potential.

The early Web services efforts were driven more by enthusiam than by
architecture. The first steps were simply to define the basic SOA
components: transport, description, and discovery. Hence the SOAP, WSDL, and
UDDI specs. But we're still in architectural infancy. As a result we are now
dealing with confusion and interoperability issues. It's time to spend some
time ironing out an architecture that properly exploits the advantages of
all three systems: SOA, XML, and the Web.

Anne

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Monday, September 23, 2002 12:04 PM
> To: Anne Thomas Manes
> Cc: www-ws-arch@w3.org; mark.baker@sympatico.ca
> Subject: Re: WSA constraints
>
>
> Anne, thanks for the technical feedback!
>
> On Mon, Sep 23, 2002 at 10:41:09AM -0400, Anne Thomas Manes wrote:
> > I disagree. I don't think the *architecture* is constrained by the
> > capabilities of SOAP 1.1 and WSDL 1.1.
>
> I believe that the software is primarily where you have to look in
> order to be able to find out what the architecture is.  But since that
> software is written to conform to specifications, then some of the
> constraints of that architecture can be extracted by looking at the
> specs.  I think we was demonstrated this during the harvesting effort.
>
> So the specs aren't authoritative, but they can be suggestive.
>
> > I also don't agree with your list of "constraints".
> >
> > In particular, I doubt think that the architecture is not constrained to
> > client/server. Most people use Web services within the
> constraints of the
> > client/server pattern, but does the architecture constrain it that way?
>
> I believe so.  But recall my previous comments about how the term
> "client/server" is often misunderstood - or, perhaps more accurately
> stated, means different things in different contexts;
>
> http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0030
>
> > Doesn't the architecture also support peer-based messaging?
>
> Yes, as a special case of client/server, where a component
> simultaneously supports both the client and server role.
>
> > I agree that the Web services architecture relies on / exploits
> "layering".
> > Does that constitute a "constraint"? (Constraint implies
> limitation. The way
> > Web services uses layering removes limitations.)
>
> In this context, "constraint" doesn't suggest a limitation of function,
> only a limitation of form (in case you thought the former).  They are
> GoodThings(tm). 8-)
>
> I did think about this for a while, and could have gone either way, but
> SOAP's processing model is explicitly layered, so that convinced me that
> it was a reasonable constraint.  I could be convinced otherwise,
> however, since few (if any) Web services use SOAP intermediaries.
>
> > I agree with Dave that XML messaging is a constraint. Web services
> > participants communicate by passing XML messages. If two applications
> > communicate using anything other than XML messages, then they
> are not using
> > the Web services architecture.
>
> Not even GET? Just kidding 8-).  I'm ok with that constraint, because
> existing Web services, and SOAP 1.1, don't support GET, just pure XML.
> Maybe we'll have to adjust this in the future, when accounting for
> SOAP 1.2 based Web services.
>
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com
>

Received on Monday, 23 September 2002 18:27:25 UTC