Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 88128 invoked from network); 25 Jan 2005 09:04:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 25 Jan 2005 09:04:30 -0000 Received: (qmail 75374 invoked by uid 500); 25 Jan 2005 09:04:29 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 75351 invoked by uid 500); 25 Jan 2005 09:04:29 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 75334 invoked by uid 99); 25 Jan 2005 09:04:29 -0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_50_60,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from mtagate1.uk.ibm.com (HELO mtagate1.uk.ibm.com) (195.212.29.134) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 25 Jan 2005 01:04:28 -0800 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j0P93qxr074714 for ; Tue, 25 Jan 2005 09:03:56 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j0P93qIf162488 for ; Tue, 25 Jan 2005 09:03:52 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0P93qAH004292 for ; Tue, 25 Jan 2005 09:03:52 GMT Received: from d06ml068.portsmouth.uk.ibm.com (d06ml068.portsmouth.uk.ibm.com [9.149.38.194]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j0P93qSj004289 for ; Tue, 25 Jan 2005 09:03:52 GMT In-Reply-To: <000001c502b8$9e9cc780$0265a8c0@rangika> To: "Apache AXIS C Developers List" MIME-Version: 1.0 Subject: Re: Design Architecture X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: John Hawkins X-MIMETrack: S/MIME Sign by Notes Client on John Hawkins/UK/IBM(Release 6.0.2CF1|June 9, 2003) at 25/01/2005 09:03:35, Serialize by Notes Client on John Hawkins/UK/IBM(Release 6.0.2CF1|June 9, 2003) at 25/01/2005 09:03:35, Serialize complete at 25/01/2005 09:03:35, S/MIME Sign failed at 25/01/2005 09:03:35: The cryptographic key was not found, Serialize by Router on D06ML068/06/M/IBM(Release 6.51HF338 | June 21, 2004) at 25/01/2005 09:08:00, Serialize complete at 25/01/2005 09:08:00 Message-ID: Date: Tue, 25 Jan 2005 09:07:59 +0000 Content-Type: multipart/alternative; boundary="=_alternative 0031C47F80256F94_=" X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This is a multipart message in MIME format. --=_alternative 0031C47F80256F94_= Content-Type: text/plain; charset="US-ASCII" Cool :-) Where is this doc going to go ? John Hawkins "Rangika Mendis" 25/01/2005 08:17 Please respond to "Apache AXIS C Developers List" To "Apache AXIS C Developers List" cc Subject Design Architecture ws-attachments - Server Side ================== Purpose - To handle Attachments at server side. A sample has been currently written to echo attachments to the client. The overall architecture is as follows: When Axis C++ server side receives a SOAP message with attachment(s) it has to extract and store it. This is done inside the Apache module. It extracts the attachments and stores inside a map. Then at any time if a webservice requests for a particular attachment, the transport (in this case the Apache2 module) will be able to provide it by taking it from its map. Also if a webservice needs to send an attachment back, it needs support to add them to the Serializer. This functionality is also provided. The details given below explain the functionalities that are needed to deal with attachments (Currently we have focused on echoing attachments to the client.) 1. Apache2Transport - The following methods will be called by getBytes() once it receives the incoming message with base64 encoded attachments. extract_Attachment(pBuffer) - Extracts the attachments from the pBuffer which has the incoming message.This will extract the attachments one by one and will store them in a map.The mime headers will also be extracted one by one & will be stored in a vector. extract_SOAPMimeHeaders(pBuffer) - Extracts the SOAPMimeHeaders from the pBuffer and will store them in a char pointer.This method is required to send the response to the client. extract_Soap(pBuffer) - Extracts the soap Message from the pBuffer.The soap part is extracted because the deserializer fails when it receives data in MIME format. It can only handle data in XML format. The above 3 methods are implemented in the AttachmentHelper class. 2. The wrapper of the webservice calls the:- getElementAsString() in the deserializer to get the ID of the required web service. Then it will get the Attachment through the DeSerializer and will send the attachment/s to the webservice to process it. Currently we are expecting the attachment id to be as an element value, but we noticed in Axis Java that it is sent as an Attribute. Axis Java TCP monitor request - Client TCP monitor request (which we used)- 000001233 3. After receiving the processed attachment/s the wrapper will pass the Id and the attachment/s to the addAttachment() of the SoapSerializer. We added the following main methods to the SoapSerializer. addAttachment(const AxisChar* achId, ISoapAttachment* pAttach) - This will add the attachment(s) to the attachment map in the Serializer. addAttachmentHeader(const AxisChar* achId, const AxisChar* achHeaderName, const AxisChar* achHeaderValue) - This will add the name & the value of the mime headers to the relavent Attachment.This in turn will store the mime headers in a vector. addAttachmentBody(const AxisChar* achId, xsd__base64Binary *pAttchBody) - This will set the body of the given attachment id. Comments regarding this are welcome. Regards, Nithya & Rangika --=_alternative 0031C47F80256F94_= Content-Type: text/html; charset="US-ASCII"
Cool :-)

Where is this doc going to go ?


John Hawkins


"Rangika Mendis" <rangika@opensource.lk>

25/01/2005 08:17
Please respond to
"Apache AXIS C Developers List"
To
"Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
cc
Subject
Design Architecture





ws-attachments - Server Side
==================
 
Purpose -
To handle Attachments at server side.
A sample has been currently written to echo attachments  to the client.
 
The overall architecture is as follows:
 
When Axis C++ server side receives a SOAP message with attachment(s)  it has to extract and store it. This is done inside the
 
Apache module. It extracts the attachments and stores  inside a map. Then at any time if a webservice requests for a particular
 
attachment, the transport (in this case the Apache2 module) will be able to provide it by taking it from its map. Also if a webservice
 
needs to send an attachment back, it needs  support to add them to the Serializer. This functionality is also provided.
 
The details given below explain the functionalities that are needed to deal with attachments (Currently we have focused on echoing
 
attachments to the client.)
 
1. Apache2Transport -
The following methods will be called by getBytes() once it receives the incoming message with base64 encoded attachments.
 
extract_Attachment(pBuffer) -
Extracts the attachments from the pBuffer which has the incoming message.This will extract the attachments one by one and will
 
store them in a map.The mime headers will also be extracted one by one & will be stored in a vector.

extract_SOAPMimeHeaders(pBuffer) -
Extracts the SOAPMimeHeaders from the pBuffer and will store them in a char pointer.This method is required to send the
response to the client.
 
extract_Soap(pBuffer) -
Extracts the soap Message from the pBuffer.The soap part is extracted because the deserializer fails when it receives data in
 
MIME format. It can only handle data in XML format.
 
The above 3 methods are implemented in the AttachmentHelper class.
 
2. The wrapper of the webservice calls the:-
getElementAsString() in the deserializer to get the ID of the required web service. Then it will get the Attachment through the
 
DeSerializer and will send the attachment/s to the webservice to process it.
 
Currently we are expecting the attachment id to be as an element value, but we noticed in Axis Java that it is sent as an Attribute.
 
Axis Java TCP monitor request -
 
 <soapenv:Body>
 <ns1:echo
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="urn:EchoAttachmentsService">
  <source href="cid:CB74148662CBBC03C85CAC8C456F9548"
xsi:type="ns1:DataHandler"/>
 </ns1:echo>
</soapenv:Body>
 
Client TCP monitor request (which we used)-
 
 <soapenv:Body>
 <ns1:EchoAttachment soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="urn:EchoAttachmentsService">  
 <id xsi:type="xsd:string">000001233</id>
   </ns1:EchoAttachment>
</soapenv:Body>

3. After receiving the processed attachment/s the wrapper will pass the Id and the attachment/s to the addAttachment() of  the
 
SoapSerializer. We added the following main methods to the SoapSerializer.
 
addAttachment(const AxisChar* achId, ISoapAttachment* pAttach) -
This will add the attachment(s) to the attachment map in the Serializer.
 
addAttachmentHeader(const AxisChar* achId, const AxisChar* achHeaderName, const AxisChar* achHeaderValue) -
This will add the name & the value of the mime headers to the relavent Attachment.This in turn will store the mime headers in a
vector.
 
addAttachmentBody(const AxisChar* achId, xsd__base64Binary *pAttchBody) -
This will set the body of the given attachment id.
 
Comments regarding this are welcome.
 
Regards,
Nithya & Rangika
--=_alternative 0031C47F80256F94_=--