[exprla-devel] Re: [xpl] Output mechanisms: SOAP intro
Status: Pre-Alpha
Brought to you by:
xpl2
|
From: reid_spencer <ras...@re...> - 2002-02-01 15:52:00
|
--- In xpl-dev@y..., cagle@o... wrote:
My primary misgivings with SOAP have more to do with their use as an
interface into COM components and less as a messaging protocol (it's
pretty good in that respect), and then, as mentioned, primarily
because of 1)security, 2) pushing of a procedural model into the
declarative space of distributed applications, but the latter is just
a personal bias.
I would also point out that as far as interoperability goes, the SOAP
message should be largely transparent to XPL users -- it should be
generated and consumed by the XPL framework, not explicitly written
by the XPL users themselves. This is analogous to something like
Visual Basic, where the complexity of COM is largely hidden behind
the language framework of Visual Basic. Thus an XPL object class
would handle the eventing through SOAP mechanisms, but you as an XPL
developer would never see these messages -- you'd just write event
handlers for intercepting them and rely on the framework to send the
event messages to you.
-- Kurt
----- Original Message -----
From: Richard Anthony Hein
To: xpl@e...
Sent: Friday, July 07, 2000 9:11 AM
Subject: RE: [xpl] Output mechanisms: SOAP intro
Jonathan,
Certainly SOAP is powerful. Plus it's getting worked on by many
groups, including the Apache XML project. I have no problems with
SOAP, and it would be my first choice at this point. However, let's
not confuse the issue with XSL. XSL isn't for components to
communicate. SOAP and XML-RPC are. Whatever the standard accepted
by the community will be, and I am betting on SOAP at this point, we
should use of course. SOAP will allow XPL to talk to CORBA, COM and
Java Beans. It also will facilitate communication between XPL
objects if necessary, but I am not sure it will be. Then again, if
we want COM, Beans, and CORBA to talk to XPL objects, then yes, it
will have to be wrapped in standard "envelopes" such as SOAP.
So, in the XPL programming context, making a SOAP envelope should
be simple as possible. Some people however, have expressed concern
over the fact that SOAP requires that you make the document root of
your document the SOAP envelope. Some people think that this
degrades the document, by requiring actual changes to the document.
Mind you, when the raw document is packaged in the SOAP env. it's
only then that it has to have changes, then when it's opened on the
receiving end you should be able to strip off the envelope and have
the normal document. So I am not sure why there is so much concern
about this.
Kurt's misgivings are understandable. How can we facilitate a
security model to protect against improper usage of the local
objects? I am hoping that this issue is resolved soon before SOAP is
widely accepted. But I am certain it can be overcome. In the
meantime, what should we do? Wait, build a security model for XPL
usage of SOAP, dump SOAP, or just trust it will all be OK?
This question needs to be addressed before we start talking about
how we are going to facilitate communication between heterogeneous
objects.
Richard A. Hein
-----Original Message-----
From: me@m... [mailto:me@m...]On Behalf Of Jonathan Burns
Sent: July 7, 2000 10:28 AM
To: xpl@e...
Subject: [xpl] Output mechanisms: SOAP intro
Back a couple of threads ago, Richard and I were debating XPL
Requirements for output
mechanisms or formats. XSL? Remote Procedure Calls?
I mentioned SOAP partly because Kurt had expressed misgivings
that it was TOO
powerful, providing access to local objects.
Anyway, I've just found this nicely-written introduction , on
the Microsoft developers'
network site.
The bottom line seems to be, that whatever will receive an http
POST message can
be addressed via SOAP, and quite simply.
--
Jonathan Burns; saski@w...
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
----------------------------------------------------------------------
--------
----------------------------------------------------------------------
--------
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|