Tuesday, August 03, 2004 - Posts
I'm working with a Java Web Service (Specifically, Java, Axis on Tomcat and Apache, on some flavor of The other OS) and a VB.NET 1.1 client. The service is using Basic Authentication. The code involved on my side is darned trivial:
Module Sender
Sub Main()
Dim whp As whProxy.WareHouseService
Dim resp As String
Try
whp = New whProxy.WareHouseService
whp.Credentials = New Net.NetworkCredential([hidden], [hidden])
whp.PreAuthenticate = True
whp.Timeout = 60000
resp = whp.submitOrder([val0],[val1],[val2],[val1],[val3],[val4])
Catch ex As Exception
Throw ex
Finally
whp.Dispose()
End Try
Console.ReadLine()
End Sub
End Module
After the invocation of submitOrder, the thread pauses a few seconds, then follow exception raises:
The request failed with HTTP status 505: HTTP Version Not Supported.
Ugh. Using a packet sniffing program and TinyGet, I know the request is marshalling over HTTP/1.1, which the server otherwise seems to support. I don't believe this is an error comming from my side since the sniffer shows good requests floating over. If I point this client at an .NET-base version of the service, it works.
Previous research pointed at the use of the PreAuth property, but I'm still see two requests getting generated. That behavior seems to conflict with the doc for HttpWebRequest.PreAuth. I wonder if that
that's making the service mad at me.
My counter part is able to do some magic and the service starts working for a while. Then we get this.
Thoughts? Suggestions? Ideas?
While I've never been a fan of Access ADPs for various reasons, I know some of you are using them. You might want to stop now, since there's likely to be some issues with them working well with SQL Server 2005. Mary Chipman from MS (responding to queries in the SSXE newsgroup) put it thusly:
However, for new application development, ADPs aren't looking so promising, especially if you are thinking in the Yukon timeframe. A couple of problematical issues are complex data types and CLR assemblies. Tackling these head-on in the ADP UI graphical tools in the next version of Access is a daunting challenge, to say the least.
...and...
FWIW, the Access team has moved away from recommending ADPs as a front-end to SQLS apps over the last year or so, based on several public talks given by team members at industry conferences. If you are contemplating new development with Access as a FE to a SQLS BE, you'll likely be ahead of the game with an efficiently-designed MDB/linked table solution rather than an ADP.
So by now, I think everybody gets the architecture behind Reporting Services (RS): You have a web server that uses tempates (RDLs), MetaData (from the Reporting Services Database) , Report Data from basically whatever Data Source you can reach with OleDb or ODBC and a Transformation Engine (the RS Service itself).
That's great if you want to develop Web hosted reports.
That's not so great if you want to develop reports without using a Web Server.
At least until Beta2 for Visual Studio 2005, where we should have controls that will give us query, rendering, print and print from a WinForm (and maybe a Webform) client without the need for a Reporting Services Server! How cool is that?
Kudos the Reporting Services (yet again) and thanks to Euan Garden for the 411 (yet again)
In this week's "Alter View, Create Function" I offering up answers to mostly-non-technical questions I that seem to be frequently asked about SQL Server 2005 Express (SSX). Specifically:
- Who should be interested in SSX?
- What are the limitations on SSX?
- What are the limitations on SSX?
- When is SSX a good fit in a design?
- How do I connect to SSX using TCP/IP and OLE-DB?
- How do I manage SSX databases?
- How can I get help with problems and help with my questions?
- Why did Microsoft release SSX?
- Where do I start?