ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> soapbuilders
soapbuilders
Re: [soapbuilders] SOAP Attachment - Database
by Noah Mendelsohn other posts by this author
Sep 16 2004 6:45AM messages near this date
[soapbuilders] My Collection Of Online Books | [soapbuilders] Axis C++ 1.3 Beta is released
SERVICES 
Fred Harman writes:

>  > 2) if it's better to send a XML-file embed in
>  > the SOAP message or as an attachment? The
>  > XML-file is quite small.
>  
>  The main reason to use SOAP with Attachments is to
>  allow intermediaries to process the SOAP message
>  (like looking at the headers) without requiring
>  them to decode the attachment.

The W3C is well along toward issuing the MTOM [1], XOP[2] and 
Representation Header[3] technologies as W3C Recommendations.  I believe 
these are likely, over time, to emerge as replacements for 
SOAP+Attachments in the marketplace.  Most of the major SOAP vendors I 
know expect to provide support for these technologies in future products 
(NOTE:  I should say for the record that this is not an official statement 
of support or a formal commitment to support these technologies in any 
products shipped by my employer, IBM;  I can say that we have actively 
supported the development of these recommendations.)   A well-optimized 
implementation of MTOM-enabled intermediares would provide for efficient 
inspection of headers, and XOP/MTOM provide for better unification of the 
file data into the model of the XML envelope.

>  If you are not going through an intermediary,
>  sending the XML as the SOAP body makes life
>  simpler and you don't lose anything.

I believe that's an oversimplification, depending on the XML documents to 
be sent.   In general, XML documents don't nest.  For example, if the 
document to be transmitted has an internal subset DTD (I.e. a DTD in the 
document) you can't send it as a direct child of <soap:body> .  If you need 
to preserve the encoding of your document (UTF-16 SHIF-JIS) and it's 
different from that of your envelope, then you also can't do a simple 
nesting.  Same for documents with entity references, which for the most 
part are not allowed in the body of a soap envelope.  For these reasons, a 
general solution for a document management system would be to use MTOM, 
perhaps with the new representation header, or if you prefer 
SOAP+Attachments as you suggest.

Noah

[1] http://www.w3.org/TR/soap12-mtom/
[2] http://www.w3.org/TR/xop10/
[3] http://www.w3.org/TR/soap12-rep/



--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------






        Fred Hartman <fred.hartman@[...].com> 
        09/13/2004 03:43 PM
        Please respond to soapbuilders
 
                 To: soapbuilders@[...].com
                 cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
                 Subject: Re: [soapbuilders] SOAP Attachment - Database


marcusweden wrote:

>  Hi everyone!

...clip...
>  Can someone tell me:
>  
>  1) Where I can find more information about the basic steps I have to 
>  perform? As said, I will not develop the system myself, but present a 
>  concept for how to do it. Haven't found any good information about 
>  integrating a SOAP client in an ERP. 
> 

Sorry all for this advertisement, but given that I am an employee of 
webMethods, I would use webMethods Integration Platform [1] with the 
appropriate ERP Adapter [2] and JDBC Adapter to provide integration from 
ERP systems to databases. This solution would not require IIS or a 
separate application server. The ERP Adapters often provide better 
integration to the ERP systems than the vendor's SOAP interfaces do, or 
the ERP SOAP interfaces are OEMed versions of webMethods products.

[1] http://www.webmethods.com/meta/default/folder/0000003869

[2] http://www.webmethods.com/meta/default/folder/0000003910

>  2) if it's better to send a XML-file embed in the SOAP message or as 
>  an attachment? The XML-file is quite small.

The main reason to use SOAP with Attachments is to allow intermediaries 
to process the SOAP message (like looking at the headers) without 
requiring them to decode the attachment. If you are not going through an 
intermediary, sending the XML as the SOAP body makes life simpler and 
you don't lose anything.

>  
>  3) can this be considered a web service? 
>  

I consider anything that can be defined by a WSDL and then accessed via 
SOAP messages that correspond to that WSDL as a web service.

Cheers,
Fred

>  Thanks in advance!
>  
>  Marcus




-----------------------------------------------------------------
This group is a forum for builders of SOAP implementations to discuss 
implementation and interoperability issues.  Please stay on-topic. 
Yahoo! Groups Links



 





------------------------ Yahoo! Groups Sponsor --------------------~-->  
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/W6uqlB/TM
--------------------------------------------------------------------~->  

-----------------------------------------------------------------
This group is a forum for builders of SOAP implementations to discuss implementation and int
eroperability issues.  Please stay on-topic. 
Yahoo! Groups Links

<*>  To visit your group on the web, go to:
    http://groups.yahoo.com/group/soapbuilders/

<*>  To unsubscribe from this group, send an email to:
    soapbuilders-unsubscribe@[...].com

<*>  Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved