Adobe ColdFusion spettert van nieuwe functies en mogelijkheden. Maar ik denk dat de meest belangrijke (in de zin van hoe het uw applicatieontwikkeling zal (of zou moeten) beïnvloeden) toch de ColdFusion Components zijn.

Deze maand wil ik iets uitleggen over de achtergrond van CFC's en hoe u CFC's wel en niet zou moeten gebruiken.

En omdat webservices binnen CFMX volgens het zelfde principe als CFC's werken - beide bieden functionaliteit die u kunt gebruiken, zonder dat u de achtergrond ervan hoeft te programmeren! - sluiten we dit artikel af met webservices en een potje dotNetten.

Gebruik van ColdFusion Componenten

CFC's zijn op zichzelf staande 'containers' met methoden (functies) die door andere ColdFusion pagina's aangesproken kunnen worden. Maar die ook benaderd kunnen worden vanuit andere CFC's, Flash applicaties of via het Standard Object Access Protocol (SOAP). CFC's kunnen zelfs gebruikt worden als webservices - objecten met functies die door iedere applicatie via Internet benaderd en gebruikt kunnen worden.

CFC's komen wat dit betreft dicht bij het concept van OOP: Object georiënteerd Programmeren.

Objecten - en Object georiënteerd Programmeren - is lange tijd het alleenrecht geweest van ontwikkeltalen en syntactische regels die onnodig gecompliceerd zijn. Op z'n simpelst - en op risico hiermee OOP-puristen op de kast te jagen - zijn objecten gewoon herbruikbare applicatie onderdeeltjes. "Zwarte doosjes" - magische dingen - die 'iets' doen met uw code en die met een resultaat terugkomen.

In dit opzicht lijken ze veel op 'ColdFusion Custom tags' maar zijn dit ook weer niet. Objecten bevatten - in tegenstelling tot Custom tags - meestal meerdere ingangspunten (methoden, functies). En ze kunnen aangepast worden, zonder dat er een breuk ontstaat met de functionaliteit (overerving).

CFC is eigenlijk OOP, maar dan simpeler!

CFC's bieden de kracht van objecten maar hebben de eenvoud van CFML.
Omdat ze de functionaliteit hebben van objecten zouden ze ook ontwikkeld en geschreven moeten worden met in het achterhoofd de principes voor objecten. Ze moeten functionaliteit herbergen die onafhankelijk is van de aanvragende client. Sterker: een applicatieprogrammeur zou niet eens moeten weten 'hoe' het object (de CFC) intern gegevens verwerkt. Zolang hij/zij maar weet 'wat' aan het object doorgegeven moeten worden (om het met een gewenst resultaat terug te laten keren).
In theorie zou het voor de gebruiker van een CFC zelfs worst moeten zijn indien de CFC intern compleet verandert! Zolang het maar steeds dezelfde argumenten accepteert en met het verwachte resultaat terugkeert.

Consequentie voor het schrijven van CFC's

Het mag duidelijk zijn dat deze stelregel direct consequenties heeft voor het schrijven van CFC's.
Als zodanig moeten ze dus geschreven worden met hergebruik in het achterhoofd. Dat betekend dat u in CFC's nooit aannames over de werkomgeving mag doen:

• Zo kunt u in CFC's application-, session-, client-, FORM- en zelfs Cookievariabelen gebruiken, maar zou u dit beter niet kunnen doen. Wanneer u in een CFC dit soort variabelen nodig hebt, benader ze dan niet direct vanuit de CFC, maar indirect door de variabele aan de CFC door te geven als argument.

• Op dezelfde manier zou u ook lay-out aspecten (headers, footers, tabellen) vanuit CFC's kunnen aansturen. Maar omdat de functie van CFC's juist is: contekst (data) te scheiden van presentatie, is dat ook niet zo'n geweldig idee.
  CFC's moeten gegevens retourneren: ze zouden zich geen zorgen moeten maken over aspecten die de boel op vrolijken!

Benaderbaar voor verschillende clients

Als u CFC's schrijft, zouden ze in principe dus benaderbaar moeten kunnen zijn voor verschillende soorten clienten:

• verschillende soorten webbrowsers (in verschillende versies met verschillende capaciteiten)
• Flash MX en Flash MX Remoting
• Webservices (via SOAP)
• Mobile communicatie

Lay-out, de presentatielaag vormen in deze gevallen daar duidelijk geen onderdeel van.
Dat u het maar weet...

Remote Web Service

Omdat Remote Web Services qua implementatie in ColdFusion bijna identiek zijn aan CFC's - ook dat zijn 'black boxes' waar u iets in stopt en die met een resultaat terug keren - en om u aan den lijve te laten voelen wat het werken met een 'black-box' betekent, een voorbeeld van een Web Service.

Tenzij u in het volgen van de webontwikkelindustrie er even een tijdje 'uit' heeft gelegen, heeft u ongetwijfeld wel gehoord over webservices.
In de kern bestaat een webservice uit (XML gebaseerde) applicatiefunctionaliteit die - a la CFC's - via Internet bereikbaar zijn en die door verschillende organisaties op het web beschikbaar worden gesteld.

Waarschuwing vooraf: Omdat de ontwikkeling van webservices nog in de kinderschoenen staat, kunt u mogelijk wat teleurgesteld zijn in wat er vandaag de dag aan services beschikbaar is. Op dit moment zijn de meeste webservices bedoelt als test-, concept- of betaversies.

Webservices kunt u als bouwsteentjes gebruiken in uw applicatie, zonder dat u ze zelf hoeft te schrijven. Zolang u maar weet wat 'er in' moet en 'wat' er weer 'uit' komt. (He! Klinkt bekend!). Om webservices in uw CF pagina's toe te kunnen passen hoeft u geen ingewikkelde truuks te kennen: ColdFusion en Dreamweaver verbergen gelukkig veel van de onderliggende complexiteit ervan.

Web Service voorbeeld

Om van webservices gebruik te maken, past u in CF gewoon dezelfde <CFINVOKE> en <CFINVOKEARGUMENT> tags toe die u ook al toepaste bij de ontwikkeling van CFC's. Wat dit betreft verschilt het aanroepen van een webservice niet zoveel van het aanroepen van een CFC (zie artikel: CFC's - wat zijn dat, wat kun je ermee?)

Aanroepen van een Web Service

In dit voorbeeld maakt u een wisselkoers-calculator die u in uw pagina's kunt gebruiken zonder dat u er de feitelijke code voor hoeft te creëren en zonder dat u dagelijks de actuele wisselkoersen van honderden muntsoorten hoeft bij te houden.
Het toevoegen van de webservice is niet moeilijk: Dreamweaver regelt veel voor u.

1. Zorg - voordat u start - dat u een verbinding heeft met Internet.
Dit is noodzakelijk om zodadelijk de webservice te kunnen aanspreken. Open Dreamweaver met een nieuw ColdFusion document.

2. Ga naar het Component palet (Window > Components of: Ctrl-F7) en selecteer in het afrolmenu de optie 'Web Services'.

Klik op de knop met het + teken. Het dialoogscherm "Add Using WSDL" verschijnt.

3. In het dialoogscherm"Add Using WSDL" zet u (als dit nog niet geregeld is) de Proxy Generator op ColdFusion MX. Klik op de knop met de globe en selecteer de xMethods UDDI site uit het afrolmenu. Dit opent de website van www.XMethods.net

4. Op de website van xMethods ziet u een overzicht van alle beschikbare webservices. Selecteer voor dit voorbeeld de Currency Exchange Rate service (bijna onderaan de lijst). (Kunt u deze niet zo snel vinden, zie dan onder punt 6: tip 6a)

5. Wanneer u in de website van xMethods op de hyperlink van deze service klikt krijgt u in een vervolgscherm de details van deze service te zien, inclusief de instructies hoe u deze in uw applicatie kunt gebruiken.
De details zijn op dit moment niet zo belangrijk. Het gaat om wat in deze pagina geel gearceerd weergegeven wordt, en dan met name om de URL die daarin aangegeven staat:

http://www.xmethodes/sd/2001/CurrencyExchangeService.wsdl

6. Kopieer deze URL. Ga terug naar Dreamweaver en plak deze URL in het dialoogscherm "Add Using WSDL" in het tekstveld onder 'URL of the WSDL-file'.

Tip 6a: (Kunt u de webservice op de xMethods site niet zo snel vinden, dan kunt u bovenstaande URL ook direct invoeren in het tekstveld in Dreamweaver!)

7. Klik op OK. De service wordt nu toegevoegd aan de overige services in het Component palet.

8. Om de webservice toe te voegen aan uw pagina, klikt u op de Exchange Service referentie in het Componenten palet en sleept dit in het BODY gedeelte van uw pagina. In uw bestand zou de volgende code gegenereerd moeten worden:

<cfinvoke
   webservice="http://www.xmethods.net/sd/2001/CurrencyExchangeService.wsdl"
   method="getRate"
   returnvariable="aRate">
   <cfinvokeargument name="country1" value="enter_value_here"/>
   <cfinvokeargument name="country2" value="enter_value_here"/>
</cfinvoke>

Deze code verschilt niet zoveel van die voor het aanroepen van een ColdFusion Component: een <CFINVOKE> tag om de service aan te roepen, een METHOD om de functie aan te roepen en een RETURNVARIABLE om de gegevens na verwerking terug te kunnen pakken op de pagina.

Maar in plaats van het COMPONENT attribuut (uit de CFC-versies) ziet u nu in CFINVOKE het WEBSERVICE attribuut, dat gebruikt wordt om de webservice op te roepen die we nodig hebben. In dit geval: het volledige ('harde') URL adres opgegeven naar het WSDL-bestand op de site van xMethods.

De variabelen die de webservice verwacht

In de beschrijving van de service kunt u lezen dat CurrencyExchangeService.wsdl van de aanroepende pagina twee variabelen verwacht: één voor de actuele muntsoort en één voor de muntsoort waartoe de eerste (muntsoort) omgerekend moet worden.

9. Voer boven de <CFINVOKE> tag de volgende twee <CFSET> variabelen toe:

<cfset munt1 = "euro">
<cfset munt2 = "usa">

10. Vervang in de eerste CFINVOKEARGUMENT tag de tekst "enter_value_here" met de waarde "#munt1#" en in de tweede CFINVOKEARGUMENT tag de tekst ="enter_value_here" met de waarde "#munt2#"

11. Voer een paar lege regels toe onder </CFINVOKE> en voeg daar onderstaande coderegel in:

<cfoutput> De actuele wisselkoers van 1 #munt1# naar 1 #munt2# = $ #aRate# </cfoutput>

In #aRate# (eerder gedefinieerd in het <CFINVOKE> blok, onder RETURNVARIABLE), wordt uiteindelijk het resultaat van de berekening door de webservice op uw pagina neergezet.

Het geheel zou er nu zo uit moeten zien:

---

<HTML>
<HEAD>
<TITLE>Untitled Document</TITLE>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</HEAD>

<BODY>
<cfset munt1 = "euro">
<cfset munt2 = "usa">

<cfinvoke
webservice="http://www.xmethods.net/sd/2001/CurrencyExchangeService.wsdl"
method="getRate"
returnvariable="aRate">
<cfinvokeargument name="country1" value="#munt1#"/>
<cfinvokeargument name="country2" value="#munt2#"/>
</cfinvoke>

<cfoutput> De actuele wisselkoers van 1 Euro naar 1 US Dollar = $ #aRate# </cfoutput>
</BODY>
</HTML>

---

12. Sla het bestand op als webservice_wisselkoers.cfm en run het met F12.
U zou zoiets moeten zien als:

De actuele wisselkoers van 1 euro naar 1 usa = 1.2445

Aanpassingen

Natuurlijk kunt u de waarde van de variabele munt1 of munt2 vervangen door een andere: "newzealand", "zimbabwe". "afghanistan", "albania", "aruba", "australia", "bahrain", "belgium", "botswana", "canada", "cape verde", "china", "cuba" en nog een paar meer...
Op http://www.xmethods.net/ve2/ViewListing.po?key=uuid:D784C184-99B2-DA25-ED45-3665D11A12e5 vindt u een lijst met land-opties.

En natuurlijk zou u in een voorafgaande pagina de landen dynamisch kunnen laten genereren door gebruik te maken van twee selectboxes.

En ja: natuurlijk zou u dan in die vorige pagina meteen ook een geldbedrag mee kunnen geven, dat vervolgens op de verwerkingspagina keurig netjes omgerekend wordt in het nieuwe valutabedrag.
Maar dergelijke uitbreidingen laat ik graag aan u over.

Meer informatie over Remote Web Services

Op het Net zijn honderden resources te vinden over webservices.
Eén daarvan kan ik niet genoeg prijzen en dat is XMethodes.net (http://www.xmethods.net). Afgezien van het feit dat deze site fungeert als een privaat UDDI-register bevat het een overvloedig aanbod aan (gratis) webservices.

Het enige lastige aan webservices - en dan heb ik het over het algemeen en niet alleen over de services op XMethod.net - is: uit te vissen welke variabelen een service verwacht en welke variabele(n) er teruggegeven worden aan uw aanroepende pagina.
Volgende maand duiken we dieper onder in de krochten van webservices. De conclusie zal zijn dat het (weer) moeilijker lijkt dan het feitelijk is!

www.XMethods.net
www-3.ibm.com/services/uddi/project/home/jsp
www.webservices.org