Re: [SOAP] Notes from Chicago BOF meeting

[Christopher Ferris <chris.ferris@east.sun.com>]

Rik/All,

I'm not so sure. SOAP v1.1
doesn't define *any* headers per se
other than a few optional attributes which are
required to be understood by a SOAP v1.1
application.

Specifically, the header element is defined as
being optional, and declares a single
element 'Header'. All other header elements are
application defined and *may* use any of the
SOAP v1.1 header attributes as needed.

<SOAP-ENV:Header xmlns:SOAP-ENV="...">
	<ns:myHeaderElement 
		xmlns:ns="..." 
		SOAP-ENV:mustUnderstand="1"
		SOAP-ENV:actor="..."
		SOAP-ENV:encodingStyle="...">
	    myHeaderElementValue
	</ns:myHeaderElement>
</SOAP-ENV:Header>

So, there's not much there to be considered
for ebXML headers, IMO. There are also a number
of our requirements which are not met by
SOAP v1.1. 

Specificaly:
	- multiple document support - SOAP can't 
		even handle a document in the 
		classic sense of an XML 'document' 
		because the SOAP:Envelope is the 
		root element.
	- security - SOAP v1.1 defers consideration
		of security for a later revision
	- provide migration path for accredited
	EDI...
	- avoid requirement of special encoding
	overhead (eg. base64)
	- ability to separately process the
	header and payload
	- ability to separately encrypt header
	and payload (to render payload opaque
	to routing services for privacy)
	- non-repudiation
	- reliable transmission
	
I could easily go on...

We could easily support a SOAP message as the
payload of an ebXML message. I suppose we could
go to the extreme of base64 encoding an ebXML
message as the <SOAP-ENV:Body> of a SOAP v1.1
message, but what purpose would that serve?
What real value add is there that SOAP offers us?

We discussed this issue briefly during this week's
conference call and consensus (among the few
dialed in) was that SOAP wasn't relevant to 
our work. 

I've seen no evidence as to whether BizTalk will 
use SOAP v1.1. Why should we?

I suggest that we not devote too much of our
energies during our f2f in Brussels on this
issue, we'll never get anything else done.

See you Monday,

Chris

Rik Drummond wrote:
> 
> looks like we may have too... rik
> 
> -----Original Message-----
> From: owner-ebxml-transport@lists.oasis-open.org
> [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Dick
> Brooks
> Sent: Friday, April 28, 2000 1:02 PM
> To: Ebxml
> Subject: FW: [SOAP] Notes from Chicago BOF meeting
> 
> More information from the SOAP front.
> 
> Question for the header group: Should SOAP be included as a candidate for
> ebXML headers?
> 
> Dick Brooks
> http://www.8760.com/
> 
> -----Original Message-----
> From: SOAP [mailto:SOAP@DISCUSS.DEVELOP.COM]On Behalf Of Bob Salita
> Sent: Friday, April 28, 2000 11:22 AM
> To: SOAP@DISCUSS.DEVELOP.COM
> Subject: [SOAP] Notes from Chicago BOF meeting
> 
> Here's some notes from yesterday's Chicago SOAP BOF meeting. They
> should be of general interest.
> 
> The meeting was called because Kent Sharkey, Technical Evangelist at
> Microsoft, asked to make a presentation about SOAP. We hoped to
> receive some software bits although this was not the case.
> 
> Prior to his arrival, we polled our group's opinions. 92% felt the
> proposed breakup of Microsoft into two parts (OS vs. Office) was a
> really bad idea. 92% felt Microsoft's appeal would prevail thus
> gutting Judge Jackson's decision.
> 
> The mix of favored programming languages changed. In our previous
> meeting, interests were very fragmented. This meeting 90% were
> both C++ and VB oriented, 50% used some Java, 10% were other.
> 
> Kent demonstrated Web Services which contained Microsoft's SOAP and
> ROAP implementation. I found the following info significant.
> 
> * Most importantly, Kent emphasized that Microsoft's SOAP activities,
> such as Web Services, are a work in progress. Much will change,
> many improvements are expected. Kent set our level of expectation by
> stating that Web Services will be a reference implementation, not
> an idealized implementation. There is great need and opportunity
> for additional implementations of SOAP. Including implementations
> that target COM, languages, hardware vendors, security, performance.
> Thus I hope to see additional implementations from DevelopMentor,
> IBM (hopefully open source), third party TCP/IP control vendors,
> and custom implementations. Entreprenuers take note.
> 
> * Kent felt that Web Services will be delayed another month.
> In my mind I pessimistically expect no final bits until October.
> 
> * Web Services will not initially contain an SSL implementation.
> 
> * Performance may be an issue. Expect to solve performance issues
> by clusterering.
> 
> * The SOAP 1.1 spec documents HTTP as a carrier. Expect future SOAP
> specs to include SMTP, perhaps ftp and MSMQ also.
> 
> * Future SOAP specs aren't likely to break 1.1 implementations.
> 
> * The ROAP implementation, which is the mechanism for VB programs
> to access SOAP servers, is relatively simple but by no means
> elegant.
> 
> * A SOAP IDL spec and implementation seems to be months away.
> 
> * Microsoft would like to add a web discovery mechanism that
> interrogates SOAP servers for information, such as services provided.
> Shades of Corba Trader services?
> 
> * Web Services software development is being done by the MSDN group.
> Some of the Duwamish people are on the project.
> 
> * IBM was rumored to have more SOAP developers than Microsoft.
> 
> * SOAP's momentum is continuing.
> 
> Bob.
> _____________________________________________________________________
> Bob Salita         Bob_Salita@SoftworksLtd.com     Software Developer
> Softworks Limited                             http://SoftworksLtd.com
> _____________________________________________________________________
>  Author of Softworks VBVM, a portable Visual Basic Virtual Machine.
>      Hold the Java. Run VB 5/6 programs on any computer system.
> 
> You can read messages from the SOAP archive, unsubscribe from SOAP, or
> subscribe to other
> DevelopMentor lists at http://discuss.develop.com.