[AccessD] Access Application - per unit cost

Jim Lawrence accessd at shaw.ca
Wed Apr 12 00:05:57 CDT 2006


Hi Marty:

We are following up a number of different ways but will go with the option
that provides the greatest flexibility and has the most information
available. (It might not be a .Net choice as there seems to be limited
content out... we are looking for a good 'white-paper' on the subject.)

The client's main site is a full Redhat Linux server out of Texas so the
coding may preclude other options than PHP. The implementation will be done
initially through an API designed out of Toronto which has a number of
'SOAP' function calls. The one thing that concerns me is the size of the
WSDL file... 5000 lines; a lot to cache. I wonder if performance will be
adversely affected? It is for all the function calls. I wonder if there can
be one for each function call as most of the features are not going to be
used?

Jim 
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of MartyConnelly
Sent: Monday, April 10, 2006 10:35 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Access Application - per unit cost

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.as
px

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



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list