Valid points, certainly Sam. However, it is possible to send raw SOAP/XML packets if absolutely necessary, and in some instances I feel it would definitely be worth it. I've taken the title of the thread here to mean "max interoperability", so that is what I've based my statements on. If you're going for interop, CF's generated WSDL will fail either way, due to using RPC/Encoded format for it's messages - the WS-I Basic Profile prohibits this across the board. In fact, SOAP encoding is prohibited entirely (all messages must be "literal"), so the SOAP-encoded Array would not be permitted either! I'm being a stickler here, but again I'm going by my interpretation of the thread title. I'm not trying to say that WSDL-first will be flawless or painless, just that it is a better approach (IMHO) when interop is a concern.
The WS-I can make the case a little better than I can, so for those interested: http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.html And Matt Liotta has a nice chapter in the ColdFusion MX Developer's Handbook on WS that covers manual SOAP packet techniques, etc. Scott > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Samuel R. Neff > Sent: Saturday, February 07, 2004 2:23 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Achieving max compatibility for Web Service > > Scott, > > The problem with WSDL first methodologies is that most > platforms do impose some requirements on the WSDL. > ColdFusion especially is very restrictive. > It does things a certain way and no matter what you do to the > WSDL you're not going to change the SOAP generated by CF. > The SOAP must match the WSDL so you're only option is to make > a matching WSDL. > > > Stacy, > > I think you're on the right track of adding an array > container manually, except the soap encoding standard defines > some array standard. I don't remember what it is off hand > but the basic methodology is defining an element of type > array and specifying the array contents. It's a little more > involved then just specifying min/max occurs. > > Remember, the WSDL has to match the SOAP generated by CF. I > haven't tried it but perhaps taking the SOAP and reverse > engineering it back to XSD with a tool like XMLSpy might be > the way to go. Certainly worth a shot. > > HTH, > > Sam > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Scott Keene > > Sent: Saturday, February 07, 2004 12:20 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] Achieving max compatibility for Web Service > > > > Hi Stacy - > > > > Actually, if min and maxOccurs are not specified, they both > default to > > 1. So you would need to edit the WSDL to get the results > that you are > > looking for in this case. > > > > You might think of it is a maintenance hazard, but really you gain > > some advantages by having an isolated WSDL document (and doing WSDL > > first has become the recommended way by most WS "heavyweights" > > anyway). Rather than thinking of the WSDL as something that the CFC > > generates and something that is attached to the CFC itself, think > > about it as an interface to the service you are providing, one that > > very clearly defines the semantics of the service, apart from the > > implementation. > > You can change the implementation (even to a different > > platform) without killing clients easily in this way. > > Also, when you go implementation-to-WSDL, you are letting > your tools > > dictate the semantics of this interface for all parties > involved (now > > and in the future), and likely requiring lots of data > mapping, etc. If > > you go WSDL-to-implementation, you are dictating the > semantics based > > on standards (XML/Schema/SOAP,etc), which reduces the need for such > > heavy translation. > > > > That's my take on it anyway! > > > > HTH, > > Scott Keene > > http://www.cfoop.com > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Stacy Young > > > Sent: Friday, February 06, 2004 11:41 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [CFCDev] Achieving max compatibility for Web Service > > > > > > > > > Dear WSDL gurus, > > > > > > Ok I've managed to get my CFC to return the following: > > > > > > (clip from WSDL) > > > > > > <complexType name="lineitem"> > > > <sequence> > > > <element name="accountNumber" nillable="true" > > > type="xsd:double"/> > > > <element name="amount" nillable="true" type="xsd:double"/> > > > <element name="customerName" nillable="true" > > > type="xsd:string"/> > > > <element name="merchantTxnId" nillable="true" > > > type="xsd:string"/> > > > <element name="txnId" nillable="true" type="xsd:double"/> > > > </sequence> > > > </complexType> > > > > > > <complexType name="lineitemarray"> > > > <sequence> > > > <element name="lineItem" nillable="true" > > type="impl:lineitem"/> > > > </sequence> > > > </complexType> > > > > > > The above replaces my query object approach...but I'm > > wondering if I > > > need to add the following in the second type > > > definition: > > > > > > <complexType name="lineitemarray"> > > > <sequence> > > > <element minOccurs="0" maxOccurs="unbounded" name="lineItem" > > > nillable="true" type="impl:lineitem"/> > > > </sequence> > > > </complexType> > > > > > > The minOccurs and maxOccurs tells the client there can be n > > lineitems > > > in this lineitemarray...should I include this manually by > > editing my > > > WSDL (maintenance hazard) or is this implied by default? > Or does it > > > even matter at all? > > > > > > Thanks! > > > > > > Stace > > > > > > > > > > > > > > > AVIS IMPORTANT: > > > ------------------------------- > > > Les informations contenues dans le present document et ses pieces > > > jointes sont strictement confidentielles et reservees a > > l'usage de la > > > (des) personne(s) a qui il est adresse. Si vous n'etes pas le > > > destinataire, soyez avise que toute divulgation, > > distribution, copie, > > > ou autre utilisation de ces informations est strictement > > prohibee. Si > > > vous avez recu ce document par erreur, veuillez s'il vous plait > > > communiquer immediatement avec l'expediteur et detruire > ce document > > > sans en faire de copie sous quelque forme. > > > > > > WARNING: > > > ------------------------------- > > > The information contained in this document and attachments is > > > confidential and intended only for the person(s) named above. > > > If you are not the intended recipient you are hereby > > notified that any > > > disclosure, copying, distribution, or any other use of the > > information > > > is strictly prohibited. If you have received this document > > by mistake, > > > please notify the sender immediately and destroy this > document and > > > attachments without making any copy of any kind. > > > > > > ---------------------------------------------------------- > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > > [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > > in the message of the email. > > > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > > Mindtool, > > > Corporation (www.mindtool.com). > > > > > > An archive of the CFCDev list is available at > > > www.mail-archive.com/[EMAIL PROTECTED] > > > > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email to > > [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > Mindtool, > > Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
