It totally does make all the sense.
The PHP issue you mention, among other unknown interpretability issues,
was my first fear in letting Visual Studio auto-generate a mass amount
of code. Seems that the contract-first approach would take more time
and knowledge but it could be pounded...err molded to fit easier.
Walden, on another note I am trying to figure out an approach to
exposing XA's System-Link to the world. The service on iSeries responds
to SOAP-less HTTP POSTs. The content of the message is XA's XML syntax
defined by SystemLinkRequest.DTD and SystemLinkResponse.DTD. So I
figured that I can build a client and use
System.Net.HttpWebRequest/Response to pass the XML back and forth. What
I don't understand is how to form the XML messages within the code?
There must be a way to use the DTD to my advantage.
[iSeries] <-- httpWebReq/Resp SystemLink XML --> [WCF.svc] ----- Methods
(GetCustomer(),UpdateCustomer())
-----Original Message-----
From: systemidotnet-bounces@xxxxxxxxxxxx
[mailto:systemidotnet-bounces@xxxxxxxxxxxx] On Behalf Of Walden H.
Leverich
Sent: Tuesday, January 12, 2010 1:11 PM
To: .net use with the System i
Subject: Re: [SystemiDotNet] Web Service Session State
Contract-first makes a ton of sense.
One word of caution with WCF (well, actually w/PHP)... PHP's SOAP
consumer doesn't like the WSDL that WCF creates. WCF will create a WSDL
w/multiple endpoints, one for SOAP, one for binary TCP, etc. But PHP's
consumer will barf when it sees the non-soap endpoint. Reported as a PHP
bug here:
http://bugs.php.net/bug.php?id=50698 but figured I'd save you
running into it if your consumer is PHP.
-Walden
midrange.com
