[exprla-devel] Re: [xpl] Output mechanisms: SOAP intro

[reid_spencer <ras...@re...>]

--- 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 ---