-----Original Message-----
Hi,
The problems that I understand need solving are:
1. compression (in and out)
2. reading variable XML description of the parameters from the input
3. getting SQL 2000 data as XML
4. render the response as a stream
1. Compression -- I think this can be solved by using IISs compression
abilities. I think IIS comes with an ISAPI filter that allows zip
compression for in/out traffic.
If not, you could easily overwrite the ATLServer ISAPI buffer response class
to compress the content on the fly and add a custom header to the response
For the main part of the job (reading the input and generating the streamed
output) -- one way to go is to modify the ATL Server SOAP support framework.
It is possible to completely override the SOAP input parameter parsing (and
get control by using your custom SAX handler instead of ATLS's one). Also,
it is possible to write directly to the response stream and override the
SOAP response serialization mechanism. If you think you really need to do
this and override the SOAP support, please let me know, the rest of this
messsage is about a different solution)
However, the SOAP support is intended to help in RPC/COM like invocations of
SOAP methods (with IDL support for structs, in/out parameters and basic
types).
Your application seems to have a more specialized function: get some POSTed
XML input which contains a query description (or so) , execute the query and
stream the XML from SQL Server as response.
You could just not use the ATLS SOAP support, but create a regular
(non-soap) web application and parse yourself the input XML (which may or
may not be strictly respecting the SOAP format).
Once you parse the input parameters, you can build your query and execute it
against SQL Server. The 'FOR XML AUTO' response from SQL Server can be
fetched as an IStream interface through OLEDB and, as you read from that
stream, you can render data back to the caller (by writing it to the
m_HttpResponse buffer).
The code should look like below (connecting to Northwind,
#define CONNECTION_STRING L"Provider=SQLOLEDB.1; Integrated Security=SSPI;
Data Source=localhost; Initial Catalog=Northwind"
#define CHECK_ERROR(x) (hr=x; if (!SUCCEEDED(hr))goto err
HRESULT hr;
CDataSource dataSrc;
CSession session;
CCommand<CNoAccessor, CStreamRowset> cmd;
CHECK_ERROR(dataSrc.OpenFromInitializationString (CONNECTION_STRING));
CHECK_ERROR(session.Open(dataSrc));
CHECK_ERROR(cmd.Open(session, "SELECT * from Customers FOR XML AUTO"));
CHAR buff[1024 + 1];
ULONG cbRead = 1024;
do
{
CHECK_ERROR(cmd.m_spStream->Read( buff, 1024, &cbRead));
buff[cbRead] = '\0';
m_HttpResponse.Write(buff);
}while( cbRead == 1024 );
err:
return SomeError;
This way, the XML data coming from the SQL Server is directly streamed to
the HTTP response without loading it into intermediary XML classes (either
unmanaged DOM or .Net)
So, if you decide to go with this second approach (regular web application
instead of using the SOAP support), you 'll get:
- good performance for writing the query result as XML back to the caller,
without using intermediate classes and without intermediate copy operations
- good database connection performance (ATL Server has a mechanism to cache
database connections)
- ability to expose a SOAP -like behavior for the clients (without actually
using the ATL Server SOAP support) -- you will have to parse the input and
make sure it looks like <soap:Envelope... etc
Also, to implement SOAP you will have to wrap the response from the SQL
Server in a <soap:Envelope><soap:Body> set of tags
- ability to switch with minimal effort to a HTTP GET behavior (you'll just
need to get the parameters from the QueryString collection instead opf
parsing a POSTed input XML document)
Besides, you don't need to modify the ATLS SOAP framework
Please let me know if this works for you and if you would like a small
working sample of this
Optimization suggestion:
- the SQL Server connection should be cached in the ISAPI DLL (the ATLS
wizard allows you to create a database connection cache in the ISAPI dll)
- if you decide to have POST-ed XML as input (instead of HTTP GET or POST
parameters), you could use the per-thread ISAXXMLReader that available in
ISAPI DLLs
- you might want to change the default buffer size for the HTTP Response
depending on the values you use when reading from the CStreamRowset in the
code above
--
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. It is for newsgroup
purposes only.
thanks,
bogdan
Hi, Bogdan,
I am writing some functions to provide data via
internet with ATL Server structure in VC++.NET.
The input to these functions has the following
feature:
* it may change in data format or/and the number
of variables.
* I am thinking to pass such a dynamic varaible
set with XML doc. The web service will parse
the input XML doc and decide what to do on
server side.
* it may be beter to compress the data before
send it to web server. If this is quite easy
to implement with .NET classes. I will do it.
The output of these functions has the following
feature:
* The results are from SQL Server 2000.
* I want to return the data with XML doc, so
as to use the data cross platform.
* it may be beter to compress the data before
send it back to client. Again, if this is quite
easy to implement with .NET classes. I will do it.
I know that one of the solutions is to implement the
input and output as string or binary string (in the
case of compressed data). But I cannot find an good
example to:
* get data in XML format from SQL Server 2000 in
ATL Server application (by using "for XML"
clause with SQL 2000);
* convert the XML doc to a string in a very
efficient way (instead of node by node by
navigating through the XML tree)
* compress the string into a binary string before
sending it back to client.
* decide a better choice between HTTP GET/POST and
ATL Server web service (I am not sure if I should
go to web service wizard project for this. But
I am sure I want to use ATL server project for
beter performance.).
Please advise.
Thank you very much.
FS Liu
.
