MartyConnelly
martyconnelly at shaw.ca
Mon Apr 10 12:35:20 CDT 2006
Take this with the caveat, I have not touched any SOAP in six months. Whether this stuff below may cause you problems, I don't know but here is what you may run into. If you are going to do anything complex in SOAP, you are going to have to make a design decision. You could use VB6 and/or Access with SOAP but the Microsoft SOAP Toolkit that made it easier at one time has been deprecated by the .NET Framework. July 2004 Maybe MS force play to use .Net. Access 2003 Web Services will generally work with the MS .Net Servers of WebServices and build the proper proxy SOAP classes but it may get into problems on Web Services built with say Java and Apache. This is what I don't know. It is generally referred to as the "SOAP Interop" problem. If you run into it, here is a possible workaround. http://msdn.microsoft.com/webservices/webservices/building/soaptk/default.aspx I could once write basic SOAP xml and throw it at a WSDL file through Access but it has become more complicated. What I did about two years ago was use open source PocketSoap Toolkit and then the WSDL Wizard for PocketSOAP 2.3.0 to run from Access 97. http://www.pocketsoap.com/wsdl/wsdl2.aspx The wizard contains support for generating proxies for rpc/encoded and document/literal services, complexTypes and custom serializers for those types are constructued from the WSDL and XSD schema information. The proxy object is generated in form of a VB6 project, I just grab the classes into Access 2003. You can also put into a COM dll and call that. So your choice maybe use Access/VB with Pocket Soap or other 3'd party toolkit or go to .Net or gasp Java. One of the major problems I had was with so called "SOAP Interop", Web servers like Apache and Tomcat had completely different ideas on the SOAP standard. I think it is finally straightened out but ... One problem being by default Web Services built with ASP.NET, default to a style of SOAP called document/literal. PocketSOAP by default uses a different style of SOAP called RPC/Encoded as does Apache/Tomcat based ones. You can either switch your ASP.NET service to RPC/Encoded mode by using the SoapRpcMethod attribute, or alternatively, you can alter your PocketSOAP code to use document/literal style mess. The Linux servers Web Services had all sorts of weird stuff that consequently got into problems when people started using the Soap Standards Section 5 encoding model, including arrays, sparse arrays, partial arrays, unsized arrays, nil's, complex types and simple types. ie things like passing VB6 objects or binary jpegs. This wasn't touched upon in the first years of SOAP. This doesn't touch other quirks, like in HTTP 1.1 transport including support for SSL, proxy servers, basic authentication, proxy server authentication, redirects, session cookies and compression. Jim Lawrence wrote: >Hi Marty: > >Thanks for the info. The YATT looks like a great tool. > >Our programmer has a sample site that is working without using a >purchased/rented API. Hopefully the API the client is paying for works as >well and has as much functionality. (Will have to get up to speed in SOAP as >I am still at the functional level with XML; time to hit the W3C pages). > >If you have any further thoughts or recommendations it would all be greatly >appreciated. > >Jim > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly >Sent: Sunday, April 09, 2006 12:01 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] Access Application - per unit cost > >Well here are tools that you may have to use, if you get stuck. >TCPTrace, YATT or PcapTrace are essentially tools that log everything >going back and forth on the wire. >I had to use on an amazon uk bookstore site when they weren't giving me >enough info >and they were making initial development mistakes. Useful, if they are >throwing things >like logging or session cookies at you, without telling you. >Simon Fell is generally about 6 months ahead of microsoft, especially >with SOAP development. >http://www.pocketsoap.com/yatt/ > >Jim Lawrence wrote: > > > >>Hi Marty: >> >>I guess this is one of the practical issues/problems with screen scrapping. >>This is why I believe it could become a full-time occupation just to keep >>the connections. The client wants start off using an existing API and maybe >>move to custom one if that does not fill the bill. The client is >>viewing/scrapping a specific set of sites. The sites that will be viewed >> >> >are > > >>ones that would want the general public to view them as easily as possible. >> >>So we will see. If there are any other suggestions that you have I would be >>more than glad to hear them. >> >>Thanks >>Jim >> >>-----Original Message----- >>From: accessd-bounces at databaseadvisors.com >>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly >>Sent: Friday, April 07, 2006 9:52 PM >>To: Access Developers discussion and problem solving >>Subject: Re: [AccessD] Access Application - per unit cost >> >>Just one thing to keep in mind about screen scraping sites, companies >>have a habit of doing a complete >>web site redesign every 12 to 18 months, not to mention minor monthly >>changes which may prove to be a problem. >>Also some sites are putting in methods that may defeat older scraping >>methods, like logging in with >>a graphic designed login code parameter, page redirects or in ASP.Net >>you may not be able to see the screen source. >>Some of these are designed on puropse to defeat screen scraping. Some >>companies like e-Bay provide a free API >>to make it easy to collect data. Some companies provide an extra paid >>for service to ftp or download the data as an Excel file. >>Yahoo financial does this. Some companies may switch entirely to a free >>or payment based WebService like USPS. >>You could be programming against moving goalposts. >> >>Jim Lawrence wrote: >> >> >> >> >> >>>Hi All: >>> >>>Good news. After the client and I sat down for a conversation we hammered >>>out a good deal. We have managed to ink-out a contract that both of us can >>>live with. He admitted that he does not trust programmers after being >>>'ripped' in a couple of instances. >>> >>>Dealing with an old coder like me seemed calm things down and we have a >>> >>> >>> >>> >>deal >> >> >> >> >>>that may see a solid ongoing full-time contract coming out of this. >>> >>>Thanks so much for all your suggestions. They definitely help put things >>> >>> >in > > >>>perspective. >>> >>>Jim >>> >>>PS So there is something that you young punk programmers do not have. >>> >>>-----Original Message----- >>>From: accessd-bounces at databaseadvisors.com >>>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence >>>Sent: Friday, April 07, 2006 2:44 PM >>>To: 'Access Developers discussion and problem solving' >>>Subject: Re: [AccessD] Access Application - per unit cost >>> >>>Thank you all for your suggestions. >>> >>>I have planned to verbally submit an appropriate counter offer and let the >>>project go if there is no agreement >>> >>>Jim >>> >>>-----Original Message----- >>>From: accessd-bounces at databaseadvisors.com >>>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence >>>Sent: Friday, April 07, 2006 7:42 AM >>>To: 'Access Developers discussion and problem solving' >>>Subject: [AccessD] Access Application - per unit cost >>> >>>These are interesting times. >>> >>>Yesterday a programmer who is working with my company went to see a new >>>client as I was out of the city for a couple of days on business. >>> >>>The client would like a custom made complex piece of code that would >>> >>> >>> >>> >>'screen >> >> >> >> >>>scrape' from other web sites so his site would be able to present a list >>> >>> >of > > >>>the best prices... a good idea. We had previously agreed on principle but >>>had not negotiated a price. >>> >>>The client presented the young programmer with his position. >>>First, we were to be on an hourly rate or when ever the client called. >>>Second, the client would pay the programmer directly and not go through >>> >>> >the > > >>>company. >>>Third, the maximum rate he would pay would be $12.00 and hour as he had >>> >>> >two > > >>>'east Indian' programmers, who had submitted bids of $5.00 per hour but >>> >>> >>> >>> >>felt >> >> >> >> >>>that he should try and support local talent. >>> >>>.. and a rider.. >>> >>>The client wants all code made to be his and if we ever used similar code >>>again, in another paying contract we would pay him 50% of gross profits. >>> >>>I must say, I am almost speechless but please feel free to comment. >>> >>>Jim >>> >>> >>> >>> >>> >>> > > > -- Marty Connelly Victoria, B.C. Canada