discontinued / server · Files

REC-wsdl20-primer-20070626.1 255 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366 4367 4368 4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404 4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417 4418 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435 4436 4437 4438 4439 4440 4441 4442 4443 4444 4445 4446 4447 4448 4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482 4483 4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507 4508 4509 4510 4511 4512 4513 4514 4515 4516 4517 4518 4519 4520 4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662 4663 4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678 4679 4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692 4693 4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726 4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739 4740 4741 4742 4743 4744 4745 4746 4747 4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768 4769 4770 4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808 4809 4810 4811 4812 4813 4814 4815 4816 4817 4818 4819 4820 4821 4822 4823 4824 4825 4826 4827 4828 4829 4830 4831 4832 4833 4834 4835 4836 4837 4838 4839 4840 4841 4842 4843 4844 4845 4846 4847 4848 4849 4850 4851 4852 4853 4854 4855 4856 4857 4858 4859 4860 4861 4862 4863 4864 4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879 4880 4881 4882 4883 4884 4885 4886 4887 4888 4889 4890 4891 4892 4893 4894 4895 4896 4897 4898 4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919 4920 4921 4922 4923 4924 4925 4926 4927 4928 4929 4930 4931 4932 4933 4934 4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956 4957 4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977 4978 4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993 4994 4995 4996 4997 4998 4999 5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012 5013 5014 5015 5016 5017 5018 5019 5020 5021 5022 5023 5024 5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044 5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 5061 5062 5063 5064 5065 5066 5067 5068 5069 5070 5071 5072 5073 5074 5075 5076 5077 5078 5079 5080 5081 5082 5083 5084 5085 5086 5087 5088 5089 5090 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101 5102 5103 5104 5105 5106 5107 5108 5109 5110 5111 5112 5113 5114 5115 5116 5117 5118 5119 5120 5121 5122 5123 5124 5125 5126 5127 5128 5129 5130 5131 5132 5133 5134 5135 5136 5137 5138 5139 5140 5141 5142 5143 5144 5145 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 5166 5167 5168 5169 5170 5171 5172 5173 5174 5175 5176 5177 5178 5179 5180 5181 5182 5183 5184 5185 5186 5187 5188 5189 5190 5191 5192 5193 5194 5195 5196 5197 5198 5199 5200 5201 5202 5203 5204 5205 5206 5207 5208 5209 5210 5211 5212 5213 5214 5215 5216 5217 5218 5219 5220 5221 5222 5223 5224 5225 5226 5227 5228 5229 5230 5231 5232 5233 5234 5235 5236 5237 5238 5239 5240 5241 5242 5243 5244 5245 5246 5247 5248 5249 5250 5251 5252 5253 5254 5255 5256 5257 5258 5259 5260 5261 5262 5263 5264 5265 5266 5267 5268 5269 5270 5271 5272 5273 5274 5275 5276 5277 5278 5279 5280 5281 5282 5283 5284 5285 5286 5287 5288 5289 5290 5291 5292 5293 5294 5295 5296 5297 5298 5299 5300 5301 5302 5303 5304 5305 5306 5307 5308 5309 5310 5311 5312 5313 5314 5315 5316 5317 5318 5319 5320 5321 5322 5323 5324 5325 5326 5327 5328 5329 5330 5331 5332 5333 5334 5335 5336 5337 5338 5339 5340 5341 5342 5343 5344 5345 5346 5347 5348 5349 5350 5351 5352 5353 5354 5355 5356 5357 5358 5359 5360 5361 5362 5363 5364 5365 5366 5367 5368 5369 5370 5371 5372 5373 5374 5375 5376 5377 5378 5379 5380 5381 5382 5383 5384 5385 5386 5387 5388 5389 5390 5391 5392 5393 5394 5395 5396 5397 5398 5399 5400 5401 5402 5403 5404 5405 5406 5407 5408 5409 5410 5411 5412 5413 5414 5415 5416 5417 5418 5419 5420 5421 5422 5423 5424 5425 5426 5427 5428 5429 5430 5431 5432 5433 5434 5435 5436 5437 5438 5439 5440 5441 5442 5443 5444 5445 5446 5447 5448 5449 5450 5451 5452 5453 5454 5455 5456 5457 5458 5459 5460 5461 5462 5463 5464 5465 5466 5467 5468 5469 5470 5471 5472 5473 5474 5475 5476 5477 5478 5479 5480 5481 5482 5483 5484 5485 5486 5487 5488 5489 5490 5491 5492 5493 5494 5495 5496 5497 5498 5499 5500 5501 5502 5503 5504 5505 5506 5507 5508 5509 5510 5511 5512 5513 5514 5515 5516 5517 5518 5519 5520 5521 5522 5523 5524 5525 5526 5527 5528 5529 5530 5531 5532 5533 5534 5535 5536 5537 5538 5539 5540 5541 5542 5543 5544 5545 5546 5547 5548 5549 5550 5551 5552 5553 5554 5555 5556 5557 5558 5559 5560 5561 5562 5563 5564 5565 5566 5567 5568 5569 5570 5571 5572 5573 5574 5575 5576 5577 5578 5579 5580 5581 5582 5583 5584 5585 5586 5587 5588 5589 5590 5591 5592 5593 5594 5595 5596 5597 5598 5599 5600 5601 5602 5603 5604 5605 5606 5607 5608 5609 5610 5611 5612 5613 5614 5615 5616 5617 5618 5619 5620 5621 5622 5623 5624 5625 5626 5627 5628 5629 5630 5631 5632 5633 5634 5635 5636 5637 5638 5639 5640 5641 5642 5643 5644 5645 5646 5647 5648 5649 5650 5651 5652 5653 5654 5655 5656 5657 5658 5659 5660 5661 5662 5663 5664 5665 5666 5667 5668 5669 5670 5671 5672 5673 5674 5675 5676 5677 5678 5679 5680 5681 5682 5683 5684 5685 5686 5687 5688 5689 5690 5691 5692 5693 5694 5695 5696 5697 5698 5699 5700 5701 5702 5703 5704 5705 5706 5707 5708 5709 5710 5711 5712 5713 5714 5715 5716 5717 5718 5719 5720 5721 5722 5723 5724 5725 5726 5727 5728 5729 5730 5731 5732 5733 5734 5735 5736 5737 5738 5739 5740 5741 5742 5743 5744 5745 5746 5747 5748 5749 5750 5751 5752 5753 5754 5755 5756 5757 5758 5759 5760 5761 5762 5763 5764 5765 5766 5767 5768 5769 5770 5771 5772 5773 5774 5775 5776 5777 5778 5779 5780 5781 5782 5783 5784 5785 5786 5787 5788 5789 5790 5791 5792 5793 5794 5795 5796 5797 5798 5799 5800 5801 5802 5803 5804 5805 5806 5807 5808 5809 5810 5811 5812 5813 5814 5815 5816 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=utf-8" />
<title>Web Services Description Language (WSDL) Version 2.0 Part 0:
Primer</title>

<style type="text/css" xml:space="preserve">
/*<![CDATA[*/
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }

dt.label       { display: run-in; }

li, p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

.diff-chg       { background-color: yellow; }
.diff-del       { background-color: red; text-decoration: line-through;}
.diff-add       { background-color: lime; }

table          { empty-cells: show; }

table caption {
        font-weight: normal;
        font-style: italic;
        text-align: left;
        margin-bottom: .5em;
}

div.issue {
  color: red;
}
.rfc2119 {
  font-variant: small-caps;
}

div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}

          th { color: #000000; background-color: #CCCC99; }
          span.test-assertion { background-color: #FFC0CB; }
          span.test-assertion-tr:hover { background-color: #FFC0CB; }
/*]]>*/
</style>
<link rel="stylesheet" type="text/css" href=
"http://www.w3.org/StyleSheets/TR/W3C-REC.css" />
</head>
<body>
<div class="head">
<p><a href="http://www.w3.org/"><img src=
"http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width=
"72" /></a></p>
<h1><a name="title" id="title"></a>Web Services Description
Language (WSDL) Version 2.0 Part 0: Primer</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Recommendation
26 June 2007</h2>
<dl>
<dt>This version:</dt>
<dd><a href=
"http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626">http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626</a></dd>
<dt>Latest version:</dt>
<dd><a href=
"http://www.w3.org/TR/wsdl20-primer">http://www.w3.org/TR/wsdl20-primer</a></dd>
<dt>Previous version:</dt>
<dd><a href=
"http://www.w3.org/TR/2007/PR-wsdl20-primer-20070523">http://www.w3.org/TR/2007/PR-wsdl20-primer-20070523</a></dd>
<dt>Editors:</dt>
<dd>David Booth, W3C Fellow / Hewlett-Packard</dd>
<dd>Canyang Kevin Liu, SAP Labs</dd>
</dl>
<p>Please refer to the <a href=
"http://www.w3.org/2007/06/wsdl20-errata.html"><strong>errata</strong></a>
for this document, which may include some normative
corrections.</p>
<p>This document is also available in these non-normative formats:
<a href="wsdl20-primer.pdf">PDF</a>, <a href=
"wsdl20-primer.ps">PostScript</a>, <a href=
"wsdl20-primer.xml">XML</a>, and&#160;<a href=
"wsdl20-primer.txt">plain text</a>.</p>
<p>See also <a href=
"http://www.w3.org/2003/03/Translations/byTechnology?technology=wsdl20-primer">
<strong>translations</strong></a>.</p>
<p class="copyright"><a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&#160;©&#160;2007&#160;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
(<a href="http://www.csail.mit.edu/"><acronym title=
"Massachusetts Institute of Technology">MIT</acronym></a>, <a href=
"http://www.ercim.org/"><acronym title=
"European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved.
W3C <a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href=
"http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>
</div>
<hr />
<div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2>
<p>This document is a companion to the WSDL 2.0 specification
(<em>Web Services Description Language (WSDL) Version 2.0 Part 1:
Core Language</em> [<cite><a href="#WSDL-PART1">WSDL 2.0
Core</a></cite>], <em>Web Services Description Language (WSDL)
Version 2.0 Part 2: Adjuncts</em> [<cite><a href="#WSDL-PART2">WSDL
2.0 Adjuncts</a></cite>]). It is intended for readers who wish to
have an easier, less technical introduction to the main features of
the language.</p>
<p>This primer is only intended to be a starting point toward use
of WSDL 2.0, and hence does not describe every feature of the
language. Users are expected to consult the WSDL 2.0 specification
if they wish to make use of more sophisticated features or
techniques.</p>
<p>Finally, this primer is <em>non-normative</em>. Any specific
questions of what WSDL 2.0 requires or forbids should be referred
to the WSDL 2.0 specification.</p>
</div>
<div>
<h2><a name="status" id="status"></a>Status of this Document</h2>
<p><em>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest
revision of this technical report can be found in the <a href=
"http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em></p>
<p>This is the <a href=
"http://www.w3.org/2005/10/Process-20051014/tr.html#RecsW3C">W3C
Recommendation</a> of Web Services Description Language (WSDL)
Version 2.0 Part 0: Primer for review by W3C Members and other
interested parties. It has been produced by the <a href=
"http://www.w3.org/2002/ws/desc/">Web Services Description Working
Group</a>, which is part of the <a href=
"http://www.w3.org/2002/ws/Activity">W3C Web Services
Activity</a>.</p>
<p>Please send comments about this document to the public <a href=
"mailto:public-ws-desc-comments@w3.org">public-ws-desc-comments@w3.org</a>
mailing list (<a href=
"http://lists.w3.org/Archives/Public/public-ws-desc-comments/">public
archive</a>).</p>
<p>The Working Group released a test suite along with an <a href=
"http://www.w3.org/2002/ws/desc/5/impl-report/">implementation
report</a>. A <a href="wsdl20-primer-diff.html">diff-marked version
against the previous version of this document</a> is available.</p>
<p>This document has been reviewed by W3C Members, by software
developers, and by other W3C groups and interested parties, and is
endorsed by the Director as a W3C Recommendation. It is a stable
document and may be used as reference material or cited from
another document. W3C's role in making the Recommendation is to
draw attention to the specification and to promote its widespread
deployment. This enhances the functionality and interoperability of
the Web.</p>
<p>This document is governed by the <a href=
"http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24
January 2002 CPP</a> as amended by the <a href=
"http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy
Transition Procedure</a>. W3C maintains a <a href=
"http://www.w3.org/2002/ws/desc/2/04/24-IPR-statements.html">public
list of any patent disclosures</a> made in connection with the
deliverables of the group; that page also includes instructions for
disclosing a patent. An individual who has actual knowledge of a
patent which the individual believes contains <a href=
"http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">
Essential Claim(s)</a> must disclose the information in accordance
with <a href=
"http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
section 6 of the W3C Patent Policy</a>.</p>
</div>
<div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2>
<p class="toc">1. <a href="#Introduction">Introduction</a>
<br />
&#160;&#160;&#160;&#160;1.1 <a href=
"#Prerequisites">Prerequisites</a>
<br />
&#160;&#160;&#160;&#160;1.2 <a href="#PrimerStructure">Structure of
this Primer</a>
<br />
&#160;&#160;&#160;&#160;1.3 <a href="#UseIRI">Use of URIs and
IRIs</a>
<br />
&#160;&#160;&#160;&#160;1.4 <a href="#notation">Notational
Conventions</a>
<br />
2. <a href="#basics">WSDL 2.0 Basics</a>
<br />
&#160;&#160;&#160;&#160;2.1 <a href="#basic-example">Getting
Started: The GreatH Hotel Example</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.1 <a href=
"#basics-greath-scenario">Example Scenario: The GreatH Hotel
Reservation Service</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.2 <a href=
"#basics-getting-started">Defining a WSDL 2.0 Target Namespace</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.2.1
<a href="#example-empty-shell-explanation">Explanation of
Example</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.3 <a href=
"#basics-types">Defining Message Types</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.3.1
<a href="#example-initial-types-explanation">Explanation of
Example</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.4 <a href=
"#basics-interface">Defining an Interface</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.4.1
<a href="#example-initial-interface-explanation">Explanation of
Example</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.5 <a href=
"#basics-binding">Defining a Binding</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.5.1
<a href="#example-initial-binding-explanation">Explanation of
Example</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.6 <a href=
"#basics-service">Defining a Service</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.6.1
<a href="#example-initial-service-explanation">Explanation of
Example</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.7 <a href=
"#basics-documentation">Documenting the Service</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.1.7.1
<a href="#example-initial-documentation-explanation">Explanation of
Example</a>
<br />
&#160;&#160;&#160;&#160;2.2 <a href="#wsdl-xml-representation">WSDL
2.0 Infoset, Schema and Component Model</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.2.1 <a href=
"#wsdl-infoset-diagram">WSDL 2.0 Infoset</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.2.2 <a href=
"#wsdl-schema">WSDL 2.0 Schema</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.2.2.1
<a href="#element-order">WSDL 2.0 Element Ordering</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.2.3 <a href=
"#component-model">WSDL 2.0 Component Model</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.2.3.1
<a href="#import-component">WSDL 2.0 Import and Include</a>
<br />
&#160;&#160;&#160;&#160;2.3 <a href="#more-types">More on Message
Types</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.3.1 <a href=
"#more-types-schema-inline">Inlining XML Schema</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.3.2 <a href=
"#more-types-schema-import">Importing XML Schema</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.3.3 <a href=
"#more-types-import-include-summary">Summary of Import and Include
Mechanisms</a>
<br />
&#160;&#160;&#160;&#160;2.4 <a href="#more-interfaces">More on
Interfaces</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.1 <a href=
"#more-interfaces-interfaces">Interface Syntax</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.2 <a href=
"#more-interfaces-inheritance">Interface Inheritance</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.3 <a href=
"#more-interfaces-faults">Interface Faults</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.4 <a href=
"#more-interfaces-operations">Interface Operations</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.4.1
<a href="#more-interfaces-op-attr">Operation Attributes</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.4.2
<a href="#id2295836">Operation Message References</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.4.2.1
<a href="#id2295901">The messageLabel Attribute</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.4.2.2
<a href="#id2295952">The element Attribute</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.4.2.3
<a href="#id2296126">Multiple infault or outfault Elements</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.4.4.3
<a href="#more-interfaces-meps">Understanding Message Exchange
Patterns (MEPs)</a>
<br />
&#160;&#160;&#160;&#160;2.5 <a href="#more-bindings">More on
Bindings</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.5.1 <a href=
"#more-bindings-wsdl">Syntax Summary for Bindings</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.5.2 <a href=
"#more-bindings-reusable">Reusable Bindings</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.5.3 <a href=
"#more-bindings-faults">Binding Faults</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.5.4 <a href=
"#bindingOperations">Binding Operations</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.5.5 <a href=
"#more-bindings-soap">The SOAP Binding Extension</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.5.5.1
<a href="#more-bindings-soap-example-explanation">Explanation of
Example</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.5.6 <a href=
"#more-bindings-http">The HTTP Binding Extension</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.5.6.1
<a href="#id2297429">Explanation of Example</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;2.5.7 <a href=
"#adv-get-vs-post">HTTP GET Versus POST: Which to Use?</a>
<br />
3. <a href="#advanced-topic_ii">Advanced Topics I: Importing
Mechanisms</a>
<br />
&#160;&#160;&#160;&#160;3.1 <a href=
"#adv-import-and-authoring">Importing WSDL</a>
<br />
&#160;&#160;&#160;&#160;3.2 <a href=
"#adv-multiple-inline-schemas">Importing Schemas</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;3.2.1 <a href=
"#id2298427">Schemas in Imported Documents</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;3.2.2 <a href=
"#id2298802">Multiple Inline Schemas in One Document</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;3.2.3 <a href=
"#adv-schema-location">The schemaLocation Attribute</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;3.2.3.1
<a href="#id2299144">Using the id Attribute to Identify Inline
Schemas</a>
<br />
4. <a href="#advanced-topic_iii">Advanced Topics II: Extensibility
and Predefined Extensions</a>
<br />
&#160;&#160;&#160;&#160;4.1 <a href=
"#adv-extensibility">Extensibility</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;4.1.1 <a href=
"#adv-optional-versus-required">Optional Versus Required
Extensions</a>
<br />
&#160;&#160;&#160;&#160;4.2 <a href="#adv-MEP">Defining New
MEPs</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;4.2.1 <a href=
"#challenge-confirm">Confirmed Challenge</a>
<br />
&#160;&#160;&#160;&#160;4.3 <a href="#adv-RPCstyle">RPC Style</a>
<br />
5. <a href="#advanced-topic_iv">Advanced Topics III:
Miscellaneous</a>
<br />
&#160;&#160;&#160;&#160;5.1 <a href=
"#adv-message-dispatch">Enabling Easy Message Dispatch</a>
<br />
&#160;&#160;&#160;&#160;5.2 <a href="#adv-versioning">Web Service
Versioning</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.1 <a href=
"#adv-versioning-compatible-evolution">Compatible Evolution</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.2 <a href=
"#adv-versioning-big-bang">Big Bang</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.3 <a href=
"#ad-versioing-migration">Evolving a Service</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.4 <a href=
"#adv-versioning-combined">Combined Approaches</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.5 <a href=
"#adv-versioning-examples">Examples of Versioning and Extending a
Service</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.5.1
<a href="#id2301152">Additional Optional Elements Added in
Content</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.5.2
<a href="#id2301217">Additional Optional Elements Added to a
Header</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.5.3
<a href="#id2301271">Additional Mandatory Elements in Content</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.5.4
<a href="#id2301354">Additional Optional Operation Added to
Interface</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.5.5
<a href="#id2301385">Additional Mandatory Operation Added to
Interface</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.5.6
<a href="#id2301454">Indicating Incompatibility by Changing the
Endpoint URI</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.5.7
<a href="#id2301490">Indicating Incompatibility by Changing the
SOAP Action</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.2.5.8
<a href="#id2301552">Indicating Incompatibility by Changing the
Element Content</a>
<br />
&#160;&#160;&#160;&#160;5.3 <a href=
"#adv-service-references">Describing Web Service Messages That
Refer to Other Web Services</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.3.1 <a href=
"#reservationDetails">The Reservation Details Web Service</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.3.2 <a href=
"#reservationList">The Reservation List Web Service</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.3.3 <a href=
"#reservationDetails_HTTP">Reservation Details Web Service Using
HTTP Transfer</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.3.4 <a href=
"#reservationList_HTTP_GET">Reservation List Web Service Using HTTP
GET</a>
<br />
&#160;&#160;&#160;&#160;5.4 <a href=
"#adv-multiple-docs-describing-same-service">Multiple Interfaces
for the Same Service</a>
<br />
&#160;&#160;&#160;&#160;5.5 <a href="#adv-rdf-mapping">Mapping to
RDF and Semantic Web</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.5.1 <a href=
"#adv-rdf-rep-wsdl">RDF Representation of WSDL 2.0</a>
<br />
&#160;&#160;&#160;&#160;5.6 <a href="#adv-notes-on-uris">Notes on
URIs</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.6.1 <a href=
"#adv-namespaces-and-schema-locations">XML Namespaces and Schema
Locations</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.6.2 <a href=
"#adv-relative-uris">Relative URIs</a>
<br />
&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.6.3 <a href=
"#adv-generating-uris">Generating Temporary URIs</a>
<br />
6. <a href="#References">References</a>
<br />
&#160;&#160;&#160;&#160;6.1 <a href=
"#Normative-References">Normative References</a>
<br />
&#160;&#160;&#160;&#160;6.2 <a href=
"#Informative-References">Informative References</a>
<br /></p>
<h3><a name="appendices" id="appendices"></a>Appendix</h3>
<p class="toc">A. <a href="#acknowledgments">Acknowledgements</a>
(Non-Normative)
<br /></p>
</div>
<hr />
<div class="body">
<div class="div1">
<h2><a name="Introduction" id="Introduction"></a>1.
Introduction</h2>
<div class="div2">
<h3><a name="Prerequisites" id="Prerequisites"></a>1.1
Prerequisites</h3>
<p>This primer assumes that the reader has the following
prerequisite knowledge:</p>
<ul>
<li>
<p>familiarity with XML (<em>Extensible Markup Language (XML)
1.0</em> [<cite><a href="#XML10">XML 1.0</a></cite>], <em>XML
Information Set</em> [<cite><a href="#XMLInfoSet">XML Information
Set</a></cite>]) and XML Namespaces (<em>Namespaces in XML</em>
[<cite><a href="#XMLNS">XML Namespaces</a></cite>]);</p>
</li>
<li>
<p>some familiarity with XML Schema (<em>XML Schema Part 1:
Structures</em> [<cite><a href="#XMLSchemaP1">XML Schema
Structures</a></cite>] <em>XML Schema Part 2: Datatypes</em>
[<cite><a href="#XMLSchemaP2">XML Schema
Datatypes</a></cite>]);</p>
</li>
<li>
<p>familiarity with basic Web services concepts such as Web
service, client, and the purpose and function of a Web service
description. (For an explanation of basic Web services concepts,
see <em>Web Services Architecture</em> [<cite><a href="#wsarch">WS
Architecture</a></cite>] <a href=
"http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#whatis">Section
1.4</a> and <em>Web Services Glossary</em> [<cite><a href=
"#WSAGLOSS">WS Glossary</a></cite>] <a href=
"http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/">glossary</a>.
However, note the <em>Web Services Architecture</em> document uses
the slightly more precise terms "<a href=
"http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#requesteragent">requester
agent</a>" and "<a href=
"http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#provideragent">provider
agent</a>" instead of the terms "client" and "Web service" used in
this primer.)</p>
</li>
</ul>
No previous experience with WSDL is assumed.</div>
<div class="div2">
<h3><a name="PrimerStructure" id="PrimerStructure"></a>1.2
Structure of this Primer</h3>
<p>Section 2 starts with a hypothetical use case involving a hotel
reservation service. It proceeds step-by-step through the
development of a simple example WSDL 2.0 document that describes
this service:</p>
<ul>
<li>
<p>The <code>types</code> element describes the kinds of messages
that the service will send and receive.</p>
</li>
<li>
<p>The <code>interface</code> element describes <em>what</em>
abstract functionality the Web service provides.</p>
</li>
<li>
<p>The <code>binding</code> element describes <em>how</em> to
access the service.</p>
</li>
<li>
<p>The <code>service</code> element describes <em>where</em> to
access the service.</p>
</li>
</ul>
<p>After presenting the example, it moves on to introduce the WSDL
2.0 infoset, schema, and component model. Then it provides more
detailed coverage on defining message types, interfaces, bindings,
and services.</p>
<p>Section 3 explains the WSDL 2.0 importing mechanisms in great
details.</p>
<p>Section 4 talks about WSDL 2.0 extensibility and various
predefined extensions.</p>
<p>Section 5 covers various topics that may fall outside the scope
of WSDL 2.0, but shall provide useful background and best practice
guidances that may be useful when authoring a WSDL 2.0 document or
implementing the WSDL 2.0 specification.</p>
</div>
<div class="div2">
<h3><a name="UseIRI" id="UseIRI"></a>1.3 Use of URIs and IRIs</h3>
<p>The core specification of WSDL 2.0 supports Internationalized
Resource Identifiers or IRIs [<cite><a href="#RFC3987">IETF RFC
3987</a></cite>]. IRIs are a superset of URIs with added support
for internationalization. The URI syntax [<cite><a href=
"#RFC3986">IETF RFC 3986</a></cite>] only allows the use of a small
set of characters, including upper and lower case letters of the
English alphabet, European numerals and a few symbols. IRIs allow
the use of characters from a wider range of language scripts.</p>
<p>For simplicity, examples throughout this primer only use URIs.
If you are interested in learning more about the use of IRIs, you
might care to read the <a href=
"http://www.w3.org/International/articles/idn-and-iri/">paper</a>
prepared by the <a href="http://www.w3.org/International/">W3C
Internationalization Activity</a>.</p>
</div>
<div class="div2">
<h3><a name="notation" id="notation"></a>1.4 Notational
Conventions</h3>
<p>This document uses several XML namespaces, some of which are
defined by standards, and some are application-specific. Namespace
names of the general form "http://greath.example.com/..." represent
application or context-dependent URIs [<cite><a href=
"#RFC3986">IETF RFC 3986</a></cite>].Note also that the choice of
any namespace prefix is arbitrary and not semantically significant
(see [<cite><a href="#XMLInfoSet">XML Information
Set</a></cite>]).</p>
<p>Following the convention for XML syntax summary in
[<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>], this primer
uses an informal syntax to describe the XML grammar of a WSDL 2.0
document:</p>
<ul>
<li>
<p>The syntax appears as an XML instance, but the values indicate
the data types instead of values.</p>
</li>
<li>
<p>Characters are appended to elements and attributes as follows:
"?" (0 or 1), "*" (0 or more), "+" (1 or more).</p>
</li>
<li>
<p>Elements names ending in "…" indicate that elements/attributes
irrelevant to the context are being omitted.</p>
</li>
</ul>
</div>
</div>
<div class="div1">
<h2><a name="basics" id="basics"></a>2. WSDL 2.0 Basics</h2>
<div class="div2">
<h3><a name="basic-example" id="basic-example"></a>2.1 Getting
Started: The GreatH Hotel Example</h3>
<p>This section introduces the basic concepts used in WSDL 2.0
through the description of a hypothetical hotel reservation
service. We start with a simple scenario, and later add more
requirements to illustrate how more advanced WSDL 2.0 features may
be used.</p>
<div class="div3">
<h4><a name="basics-greath-scenario" id=
"basics-greath-scenario"></a>2.1.1 Example Scenario: The GreatH
Hotel Reservation Service</h4>
<p>Hotel GreatH (a fictional hotel) is located in a remote island.
It has been relying on fax and phone to provide room reservations.
Even though the facilities and prices at GreatH are better than
what its competitor offers, GreatH notices that its competitor is
getting more customers than GreatH. After research, GreatH realizes
that this is because the competitor offers a Web service that
permits travel agent reservation systems to reserve rooms directly
over the Internet. GreatH then hires us to build a reservation Web
service with the following functionality:</p>
<ul>
<li>
<p><em>CheckAvailability</em>. To check availability, the client
must specify a check-in date, a check-out date, and room type. The
Web service will return a room rate (a floating point number in
USD) if such a room is available, or a zero room rate if not. If
any input data is invalid, the service should return an error.
Thus, the service will accept a <code>checkAvailability</code>
message and return a <code>checkAvailabilityResponse</code> or
<code>invalidDataFault</code> message.</p>
</li>
<li>
<p><em>MakeReservation</em>. To make a reservation, a client must
provide a name, address, and credit card information, and the
service will return a confirmation number if the reservation is
successful. The service will return an error message if the credit
card number or any other data field is invalid. Thus, the service
will accept a <code>makeReservation</code> message and return a
<code>makeReservationResponse</code> or
<code>invalidCreditCardFault</code> message.</p>
</li>
</ul>
We know that we will later need to build a complete system that
supports transactions and secured transmission, but initially we
will implement only minimal functionality. In fact, to simplify our
first example, we will implement only the
<em>CheckAvailability</em> operation.
<p>The next several sections proceed step-by-step through the
process of developing a WSDL 2.0 document that describes the
desired Web service. However, for those who can't wait to see a
complete example, here is the WSDL 2.0 document that we'll be
creating.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-initial" id="example-initial"></a><em><span>Example
2-1.</span> WSDL 2.0 Document for the GreatH Web Service (Initial
Example)</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsdlx= "http://www.w3.org/ns/wsdl-extensions"&gt;

  &lt;documentation&gt;
    This document describes the GreatH Web service.  Additional 
    application-level requirements for use of this service -- 
    beyond what WSDL 2.0 is able to describe -- are available 
    at http://greath.example.com/2004/reservation-documentation.html
  &lt;/documentation&gt;

  &lt;types&gt;
    &lt;xs:schema 
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://greath.example.com/2004/schemas/resSvc"
        xmlns="http://greath.example.com/2004/schemas/resSvc"&gt;

      &lt;xs:element name="checkAvailability" type="tCheckAvailability"/&gt;    
      &lt;xs:complexType name="tCheckAvailability"&gt;     
        &lt;xs:sequence&gt;      
          &lt;xs:element  name="checkInDate" type="xs:date"/&gt;      
          &lt;xs:element  name="checkOutDate" type="xs:date"/&gt;      
          &lt;xs:element  name="roomType" type="xs:string"/&gt;      
        &lt;/xs:sequence&gt;     
      &lt;/xs:complexType&gt;   
            
      &lt;xs:element name="checkAvailabilityResponse" type="xs:double"/&gt;    
    
      &lt;xs:element name="invalidDataError" type="xs:string"/&gt;    

    &lt;/xs:schema&gt;    
  &lt;/types&gt;
  
  &lt;interface  name = "reservationInterface" &gt;

    &lt;fault name = "invalidDataFault"
            element = "ghns:invalidDataError"/&gt; 
   
    &lt;operation name="opCheckAvailability" 
            pattern="http://www.w3.org/ns/wsdl/in-out" 
            style="http://www.w3.org/ns/wsdl/style/iri"
            wsdlx:safe = "true"&gt;
        &lt;input messageLabel="In" 
              element="ghns:checkAvailability" /&gt;
        &lt;output messageLabel="Out" 
              element="ghns:checkAvailabilityResponse" /&gt;
        &lt;outfault ref="tns:invalidDataFault" messageLabel="Out"/&gt;
    &lt;/operation&gt;

  &lt;/interface&gt;

  &lt;binding name="reservationSOAPBinding" 
          interface="tns:reservationInterface"
          type="http://www.w3.org/ns/wsdl/soap"
          wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"&gt;
 
    &lt;fault ref="tns:invalidDataFault" 
      wsoap:code="soap:Sender"/&gt;

    &lt;operation ref="tns:opCheckAvailability" 
      wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/&gt;

  &lt;/binding&gt;

  &lt;service name="reservationService" 
       interface="tns:reservationInterface"&gt;

     &lt;endpoint name="reservationEndpoint" 
               binding="tns:reservationSOAPBinding"
               address ="http://greath.example.com/2004/reservation"/&gt;
        
  &lt;/service&gt;

&lt;/description&gt;
</pre></div>
</div>
</div>
<div class="div3">
<h4><a name="basics-getting-started" id=
"basics-getting-started"></a>2.1.2 Defining a WSDL 2.0 Target
Namespace</h4>
<p>Before writing our WSDL 2.0 document, we need to decide on a
<em>WSDL 2.0 target namespace</em> URI for it. The WSDL 2.0 target
namespace is analogous to an XML Schema target namespace.
Interface, binding and service names that we define in our WSDL 2.0
document will be associated with the WSDL 2.0 target namespace, and
thus will be distinguishable from similar names in a different WSDL
2.0 target namespace. (This will become important if using WSDL
2.0's import or interface inheritance mechanisms.)</p>
<p>The value of the WSDL 2.0 target namespace must be an absolute
URI. Furthermore, it should be dereferenceable to a WSDL 2.0
document that describes the Web service that the WSDL 2.0 target
namespace is used to describe. For example, the GreatH owners
should make the WSDL 2.0 document available from this URI. (And if
a WSDL 2.0 description is split into multiple documents, then the
WSDL 2.0 target namespace should resolve to a master document that
includes all the WSDL 2.0 documents needed for that service
description.) However, there is no absolute requirement for this
URI to be dereferenceable, so a WSDL 2.0 processor must not depend
on it being dereferenceable.</p>
<p>This recommendation may sound circular, but bear in mind that
the client might have obtained the WSDL 2.0 document from anywhere
-- not necessarily an authoritative source. But by dereferencing
the WSDL 2.0 target namespace URI, a user should be able to obtain
an authoritative version. Since GreatH will be the owner of the
service, the WSDL 2.0 target namespace URI should refer to a
location on the GreatH Web site or otherwise within its
control.</p>
<p>Once we have decided on a WSDL 2.0 target namespace URI, we can
begin our WSDL 2.0 document as the following empty shell.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-empty-shell" id=
"example-empty-shell"></a><em><span>Example 2-2.</span> An Initial
Empty WSDL 2.0 Document</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    . . . &gt;

  . . .
&lt;/description&gt;
</pre></div>
</div>
<div class="div4">
<h5><a name="example-empty-shell-explanation" id=
"example-empty-shell-explanation"></a>2.1.2.1 Explanation of
Example</h5>
<dl>
<dt class="label"><code>&lt;description</code></dt>
<dd>
<p>Every WSDL 2.0 document has a <code>description</code> element
as its top-most element. This merely acts as a container for the
rest of the WSDL 2.0 document, and is used to declare namespaces
that will be used throughout the document.</p>
</dd>
<dt class="label">
<code>xmlns="http://www.w3.org/ns/wsdl"</code></dt>
<dd>
<p>This is the XML namespace for WSDL 2.0 itself. We assign it as
the default namespace for this example by not defining a prefix for
it. In other words, any unprefixed elements in this example are
expected to be WSDL 2.0 elements (such as the
<code>description</code> element).</p>
</dd>
<dt class="label"><code>targetNamespace=
"http://greath.example.com/2004/wsdl/resSvc"</code></dt>
<dd>
<p>This defines the WSDL 2.0 target namespace that we have chosen
for the GreatH reservation service, as described above. Note that
this is not an actual XML namespace declaration. Rather, it is a
WSDL 2.0 attribute whose purpose is <em>analogous</em> to an XML
Schema target namespace.</p>
</dd>
<dt class="label"><code>xmlns:tns=
"http://greath.example.com/2004/wsdl/resSvc"</code></dt>
<dd>
<p>This is an actual XML namespace declaration for use in our
GreatH service description. Note that this is the same URI that was
specified above as the value of the <code>targetNamespace</code>
attribute. This will allow us later to use the <code>tns:</code>
prefix in QNames, to refer to the WSDL 2.0 target namespace of the
GreatH service. (For more on QNames see [<cite><a href="#XMLNS">XML
Namespaces</a></cite>] section 3 <a href=
"http://www.w3.org/TR/2006/REC-xml-names-20060816/#ns-qualnames">Qualified
Names</a>.)</p>
</dd>
</dl>
<p>Now we can start describing the GreatH service.</p>
</div>
</div>
<div class="div3">
<h4><a name="basics-types" id="basics-types"></a>2.1.3 Defining
Message Types</h4>
<p>We know that the GreatH service will be sending and receiving
messages, so a good starting point in describing the service is to
define the message types that the service will use. We'll use XML
Schema to do so, because WSDL 2.0 processors are likely to support
XML Schema at a minimum. However, WSDL 2.0 does not prohibit the
use of some other schema definition language.</p>
<p>WSDL 2.0 allows message types to be defined directly within the
WSDL 2.0 document, inside the <code>types</code> element, which is
a child of the <code>description</code> element. (Later we'll see
how we can provide the type definitions in a separate document,
using XML Schema's <code>import</code> mechanism.) The following
schema defines <code>checkAvailability</code>,
<code>checkAvailabilityResponse</code> and
<code>invalidDataError</code> message types that we'll need.</p>
<p>In WSDL 2.0, all normal and fault message types must be defined
as single <em>elements</em> at the topmost level (though of course
each element may have any amount of substructure inside it). Thus,
a message type must not directly consist of a sequence of elements
or other complex type.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-initial-types" id=
"example-initial-types"></a><em><span>Example 2-3.</span> GreatH
Message Types</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    . . . &gt;

  ...

  &lt;types&gt;
    &lt;xs:schema 
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://greath.example.com/2004/schemas/resSvc"
        xmlns="http://greath.example.com/2004/schemas/resSvc"&gt;

      &lt;xs:element name="checkAvailability" type="tCheckAvailability"/&gt;    
      &lt;xs:complexType name="tCheckAvailability"&gt;     
        &lt;xs:sequence&gt;      
          &lt;xs:element  name="checkInDate" type="xs:date"/&gt;      
          &lt;xs:element  name="checkOutDate" type="xs:date"/&gt;      
          &lt;xs:element  name="roomType" type="xs:string"/&gt;      
        &lt;/xs:sequence&gt;     
      &lt;/xs:complexType&gt;   
            
      &lt;xs:element name="checkAvailabilityResponse" type="xs:double"/&gt;    
    
      &lt;xs:element name="invalidDataError" type="xs:string"/&gt;    

    &lt;/xs:schema&gt;    
  &lt;/types&gt;
  . . .
&lt;/description&gt;
</pre></div>
</div>
<div class="div4">
<h5><a name="example-initial-types-explanation" id=
"example-initial-types-explanation"></a>2.1.3.1 Explanation of
Example</h5>
<dl>
<dt class="label"><code>xmlns:ghns =
"http://greath.example.com/2004/schemas/resSvc"</code></dt>
<dd>
<p>We've added another namespace declaration. The <code>ghns</code>
namespace prefix will allow us (later, when defining an interface)
to reference the XML Schema target namespace that we define for our
message types. Thus, the URI we specify must be the same as the URI
that we define as the target namespace of our XML Schema types
(below) -- <em>not</em> the target namespace of the WSDL 2.0
document itself.</p>
</dd>
<dt class="label">
<code>targetNamespace="http://greath.example.com/2004/schemas/resSvc"</code></dt>
<dd>
<p>This is the XML Schema target namespace that we've created for
use by the GreatH reservation service. The
<code>checkAvailability</code>,
<code>checkAvailabilityResponse</code> and
<code>invalidDataError</code> element names will be associated with
this XML Schema target namespace.</p>
</dd>
<dt class="label"><code>checkAvailability</code>,
<code>checkAvailabilityResponse</code> and
<code>invalidDataError</code></dt>
<dd>
<p>These are the message types that we'll use. Note that these are
defined to be XML <em>elements</em>, as explained above.</p>
</dd>
</dl>
<p>Although we have defined several types, we have not yet
indicated which ones are to be used as message types for a Web
service. We'll do that in the next section.</p>
</div>
</div>
<div class="div3">
<h4><a name="basics-interface" id="basics-interface"></a>2.1.4
Defining an Interface</h4>
<p>WSDL 2.0 enables one to separate the description of a Web
service's abstract functionality from the concrete details of how
and where that functionality is offered. This separation
facilitates different levels of reusability and distribution of
work in the lifecycle of a Web service and the WSDL 2.0 document
that describes it.</p>
<p>A WSDL 2.0 <code>interface</code> defines the abstract interface
of a Web service as a set of abstract <em>operations</em>, each
operation representing a simple interaction between the client and
the service. Each operation specifies the types of messages that
the service can send or receive as part of that operation. Each
operation also specifies a message exchange <em>pattern</em> that
indicates the sequence in which the associated messages are to be
transmitted between the parties. For example, the <em>in-out</em>
pattern (see <em>WSDL 2.0 Predefined Extensions</em>
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section
2.2.3 <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">In-Out</a>)
indicates that if the client sends a message <em>in</em> to the
service, the service will either send a reply message back
<em>out</em> to the client (in the normal case) or it will send a
fault message back to the client (in the case of an error). We will
explain more about message exchange <em>pattern</em>s in <a href=
"#more-interfaces-meps"><strong>2.4.4.3 Understanding Message
Exchange Patterns (MEPs)</strong></a></p>
<p>For the GreatH service, we will (initially) define an interface
containing a single operation, <code>opCheckAvailability</code>,
using the <code>checkAvailability</code> and
<code>checkAvailabilityResponse</code> message types that we
defined in the <code>types</code> section. We'll use the <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>
pattern for this operation, because this is the most natural way to
represent a simple request-response interaction. We could have
instead (for example) defined two separate operations using the
<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-only</a>
and <a href=
"http://www.w3.org/TR/2007/NOTE-wsdl20-additional-meps-20070626#out-only">
out-only</a> patterns (see <em>WSDL 2.0 Predefined Extensions</em>
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section
2.2.1 <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-only">In-Only</a>
and section 2.2.5 <a href=
"http://www.w3.org/TR/2007/NOTE-wsdl20-additional-meps-20070626#out-only">
Out-Only</a>), but that would just complicate matters for the
client, because we would then have to separately indicate to the
client developer that the two operations should be used together as
a request-response pair.</p>
<p>In addition to the normal input and output messages, we also
need to specify the fault message that we wish to use in the event
of an error. WSDL 2.0 permits fault messages to be declared within
the <code>interface</code> element in order to facilitate reuse of
faults across operations. If a fault occurs, it terminates whatever
message sequence was indicated by the message exchange pattern of
the operation.</p>
<p>Let's add these to our WSDL 2.0 document.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-initial-interface" id=
"example-initial-interface"></a><em><span>Example 2-4.</span>
GreatH Interface Definition</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    . . . 
    xmlns:wsdlx="http://www.w3.org/ns/wsdl-extensions"&gt;

  . . .
  &lt;types&gt;
        ...
  &lt;/types&gt;
  
  &lt;interface  name = "reservationInterface" &gt;

    &lt;fault name = "invalidDataFault"
            element = "ghns:invalidDataError"/&gt; 
   
    &lt;operation name="opCheckAvailability" 
            pattern="http://www.w3.org/ns/wsdl/in-out"
            style="http://www.w3.org/ns/wsdl/style/iri"
            wsdlx:safe = "true"&gt;
        &lt;input messageLabel="In" 
              element="ghns:checkAvailability" /&gt;
        &lt;output messageLabel="Out" 
              element="ghns:checkAvailabilityResponse" /&gt;
        &lt;outfault ref="tns:invalidDataFault" messageLabel="Out"/&gt;
    &lt;/operation&gt;

  &lt;/interface&gt;

  . . .
&lt;/description&gt;
</pre></div>
</div>
<div class="div4">
<h5><a name="example-initial-interface-explanation" id=
"example-initial-interface-explanation"></a>2.1.4.1 Explanation of
Example</h5>
<dl>
<dt class="label"><code>&lt;interface name = "reservationInterface"
&gt;</code></dt>
<dd>
<p>Interfaces are declared directly inside the
<code>description</code> element. In this example, we are declaring
only one interface, but in general a WSDL 2.0 document may declare
more than one interface. Thus, each interface must be given a name
that is unique within the set of interfaces defined in this WSDL
2.0 target namespace. Interface names are tokens that must not
contain a space or colon (":").</p>
</dd>
<dt class="label"><code>&lt;fault name =
"invalidDataFault"</code></dt>
<dd>
<p>The <code>name</code> attribute defines a name for this fault.
The name is required so that when an operation is defined, it can
reference the desired fault by name. Fault names must be unique
within an interface.</p>
</dd>
<dt class="label"><code>element =
"ghns:invalidDataError"/&gt;</code></dt>
<dd>
<p>The <code>element</code> attribute specifies the schema type of
the fault message, as previously defined in the <code>types</code>
section.</p>
</dd>
<dt class="label"><code>&lt;operation
name="opCheckAvailability"</code></dt>
<dd>
<p>The <code>name</code> attribute defines a name for this
operation, so that it can be referenced later when bindings are
defined. Operation names must also be unique within an interface.
(WSDL 2.0 uses separate symbol spaces for operation and fault
names, so operation name "foo" is distinct from fault name
"foo".)</p>
</dd>
<dt class="label">
<code>pattern="http://www.w3.org/ns/wsdl/in-out"</code></dt>
<dd>
<p>This line specifies that this operation will use the <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>
pattern as described above. WSDL 2.0 uses URIs to identify message
exchange patterns in order to ensure that the identifiers are
globally unambiguous, while also permitting future new patterns to
be defined by anyone. (However, just because someone defines a new
pattern and creates a URI to identify it, that does <em>not</em>
mean that other WSDL 2.0 processors will automatically recognize or
understand that pattern. As with any other extension, it can only
be used among processors that <em>do</em> recognize and understand
it.)</p>
</dd>
<dt class="label">
<code>style="http://www.w3.org/ns/wsdl/style/iri"</code></dt>
<dd>
<p>This line indicates that the XML schema defining the input
message of this operation follows a set of rules as specified in
<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#_operation_iri_style">
IRI Style</a> that ensures the message can be serialized as an
IRI.</p>
</dd>
<dt class="label"><code>wsdlx:safe="true" &gt;</code></dt>
<dd>
<p>This line indicates that this operation will not obligate the
client in any way, i.e., the client can safely invoke this
operation without fear that it may be incurring an obligation (such
as agreeing to buy something). This is further explained in
<a href="#more-interfaces-operations"><strong>2.4.4 Interface
Operations</strong></a>.</p>
</dd>
<dt class="label"><code>&lt;input messageLabel="In"</code></dt>
<dd>
<p>The <code>input</code> element specifies an input message. Even
though we have already specified which message exchange pattern the
operation will use, a message exchange pattern represents a
template for a message sequence, and in theory could consist of
multiple input and/or output messages. Thus we must also indicate
which potential input message in the pattern this particular input
message represents. This is the purpose of the
<code>messageLabel</code> attribute. Since the <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>
pattern that we've chosen to use only has one input message, it is
trivial in this case: we simply fill in the message label "In" that
was defined in <em>WSDL 2.0 Predefined Extensions</em>
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] section
2.2.3 <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">In-Out</a>
for the <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>
pattern. However, if a new pattern is defined that involve multiple
input messages, then the different input messages in the pattern
could then be distinguished by using different labels.</p>
</dd>
<dt class="label"><code>element="ghns:checkAvailability"
/&gt;</code></dt>
<dd>
<p>This specifies the message type for this input message, as
defined previously in the <code>types</code> section.</p>
</dd>
<dt class="label"><code>&lt;output messageLabel="Out" . .
.</code></dt>
<dd>
<p>This is similar to defining an input message.</p>
</dd>
<dt class="label"><code>&lt;outfault ref="tns:invalidDataFault"
messageLabel="Out"/&gt;</code></dt>
<dd>
<p>This associates an output fault with this operation. Faults are
declared a little differently than normal messages. The
<code>ref</code> attribute refers to the name of a previously
defined fault in this interface -- not a message schema type
directly. Since message exchange patterns could in general involve
a sequence of several messages, a fault could potentially occur at
various points within the message sequence. Because one may wish to
associate a different fault with each permitted point in the
sequence, the <code>messageLabel</code> is used to indicate the
desired point for this particular fault. It does so indirectly by
specifying the message that will either trigger this fault or that
this fault will replace, depending on the pattern. (Some patterns
use a <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#fault-trigger">
message-triggers-fault rule</a>; others use a <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#fault-replacement">
fault-replaces-message</a> rule. See <em>WSDL 2.0 Predefined
Extensions</em> [<cite><a href="#WSDL-PART2">WSDL 2.0
Adjuncts</a></cite>] section 2.1.2 <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#fault-trigger">
Message Triggers Fault</a> and section 2.1.1 <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#fault-replacement">
Fault Replaces Message</a>.)</p>
</dd>
</dl>
<p>Now that we've defined the abstract interface for the GreatH
service, we're ready to define a binding for it.</p>
</div>
</div>
<div class="div3">
<h4><a name="basics-binding" id="basics-binding"></a>2.1.5 Defining
a Binding</h4>
<p>Although we have specified <em>what</em> abstract messages can
be exchanged with the GreatH Web service, we have not yet specified
<em>how</em> those messages can be exchanged. This is the purpose
of a <em>binding</em>. A binding specifies concrete message format
and transmission protocol details for an interface, and must supply
such details for every operation and fault in the interface.</p>
<p>In the general case, binding details for each operation and
fault are specified using <code>operation</code> and
<code>fault</code> elements inside a <code>binding</code> element,
as shown in the example below. However, in some cases it is
possible to use defaulting rules to supply the information. The
WSDL 2.0 SOAP binding extension, for example, defines some
defaulting rules for operations. (See <em>Web Services Description
Language (WSDL) Version 2.0 Part 2: Adjuncts</em> [<cite><a href=
"#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>], <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#soap-defaults">
Default Binding Rules</a>.)</p>
<p>In order to accommodate new kinds of message formats and
transmission protocols, bindings are defined using extensions to
the WSDL 2.0 language, via WSDL 2.0's open content model. (See
<a href="#adv-extensibility"><strong>4.1 Extensibility</strong></a>
for more on extensibility.) WSDL 2.0 Part 2 [<cite><a href=
"#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] defines binding
extensions for SOAP 1.2 [<cite><a href="#SOAP12-PART1">SOAP 1.2
Part 1: Messaging Framework</a></cite>] and HTTP 1.1
[<cite><a href="#RFC2616">IETF RFC 2616</a></cite>] as predefined
extensions, so that SOAP 1.2 or HTTP 1.1 bindings can be easily
defined in WSDL 2.0 documents. However, other specifications could
define new binding extensions that could also be used to define
bindings. (As with any extension, other WSDL 2.0 processors would
have to know about the new constructs in order to make use of
them.)</p>
<p>For the GreatH service, we will use SOAP 1.2 as our concrete
message format and HTTP as our underlying transmission protocol, as
shown below.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-initial-binding" id=
"example-initial-binding"></a><em><span>Example 2-5.</span> GreatH
Binding Definition</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"&gt;
  . . .

  &lt;types&gt;
    . . .
  &lt;/types&gt;
  
  &lt;interface  name = "reservationInterface" &gt;
        ...
  &lt;/interface&gt;

  &lt;binding name="reservationSOAPBinding" 
          interface="tns:reservationInterface"
          type="http://www.w3.org/ns/wsdl/soap"
          wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"&gt;

    &lt;operation ref="tns:opCheckAvailability" 
      wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/&gt;
  
    &lt;fault ref="tns:invalidDataFault" 
      wsoap:code="soap:Sender"/&gt;

  &lt;/binding&gt;

  . . .
&lt;/description&gt;
</pre></div>
</div>
<div class="div4">
<h5><a name="example-initial-binding-explanation" id=
"example-initial-binding-explanation"></a>2.1.5.1 Explanation of
Example</h5>
<dl>
<dt class="label"><code>xmlns:wsoap=
"http://www.w3.org/ns/wsdl/soap"</code></dt>
<dd>
<p>We've added two more namespace declarations. This one is the
namespace for the SOAP 1.2 binding extension that is defined in
WSDL 2.0 Part 3 [<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1:
Messaging Framework</a></cite>]. Elements and attributes prefixed
with <code>wsoap:</code> are constructs defined there.</p>
</dd>
<dt class="label">
<code>xmlns:soap="http://www.w3.org/2003/05/soap-envelope"</code></dt>
<dd>
<p>This namespace is defined by the SOAP 1.2 specification itself.
The SOAP 1.2 specification defines certain terms within this
namespace to unambiguously identify particular concepts. Thus, we
will use the <code>soap:</code> prefix when we need to refer to one
of those terms.</p>
</dd>
<dt class="label"><code>&lt;binding
name="reservationSOAPBinding"</code></dt>
<dd>
<p>Bindings are declared directly inside the
<code>description</code> element. The <code>name</code> attribute
defines a name for this binding. Each name must be unique among all
bindings in this WSDL 2.0 target namespace, and will be used later
when we define a service endpoint that references this binding.
WSDL 2.0 uses separate symbol spaces for interfaces, bindings and
services, so interface "foo", binding "foo" and service "foo" are
all distinct.</p>
</dd>
<dt class="label">
<code>interface="tns:reservationInterface"</code></dt>
<dd>
<p>This is the name of the interface whose message format and
transmission protocols we are specifying. As discussed in <a href=
"#more-bindings"><strong>2.5 More on Bindings</strong></a>, a
reusable binding can be defined by omitting the
<code>interface</code> attribute. Note also the use of the
<code>tns:</code> prefix, which refers to the previously defined
WSDL 2.0 target namespace for this WSDL 2.0 document. In this case
it may seem silly to have to specify the <code>tns:</code> prefix,
but in <a href="#adv-import-and-authoring"><strong>3.1 Importing
WSDL</strong></a> we will see how WSDL 2.0's import mechanism can
be used to combine components that are defined in different WSDL
2.0 target namespaces.</p>
</dd>
<dt class="label">
<code>type="http://www.w3.org/ns/wsdl/soap"</code></dt>
<dd>
<p>This specifies what kind of concrete message format to use, in
this case SOAP 1.2.</p>
</dd>
<dt class="label">
<code>wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"</code></dt>
<dd>
<p>This attribute is specific to WSDL 2.0's SOAP binding extension
(thus it uses the <code>wsoap:</code> prefix). It specifies the
underlying transmission protocol that should be used, in this case
HTTP.</p>
</dd>
<dt class="label"><code>&lt;operation
ref="tns:opCheckAvailability"</code></dt>
<dd>
<p>This is not defining a new operation; rather, it is referencing
the previously defined <code>opCheckAvailability</code> operation
in order to specify binding details for it. This element can be
omitted if defaulting rules are instead used to supply the
necessary information. (See the SOAP binding extension in WSDL 2.0
Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]
section 4.3 <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#soap-defaults">
Default Binding Rules</a> .)</p>
</dd>
<dt class="label">
<code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"&gt;</code></dt>
<dd>
<p>This attribute is also specific to WSDL 2.0's SOAP binding
extension. It specifies the SOAP message exchange pattern (MEP)
that will be used to implement the abstract WSDL 2.0 message
exchange pattern (<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#in-out">in-out</a>)
that was specified when the <code>opCheckAvailability</code>
operation was defined.</p>
<p>When HTTP is used as the underlying transport protocol (as in
this example) the <code>wsoap:mep</code> attribute also controls
whether GET or POST will be used as the underlying HTTP method. In
this case, the use of
<code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"</code>
causes GET to be used by default. See also <a href=
"#adv-get-vs-post"><strong>2.5.7 HTTP GET Versus POST: Which to
Use?</strong></a>.</p>
</dd>
<dt class="label"><code>&lt;fault
ref="tns:invalidDataFault"</code></dt>
<dd>
<p>As with a binding operation, this is not declaring a new fault;
rather, it is referencing a fault (<code>invalidDataFault</code>)
that was previously defined in the <code>opCheckAvailability</code>
interface, in order to specify binding details for it.</p>
</dd>
<dt class="label"><code>wsoap:code="soap:Sender"/&gt;</code></dt>
<dd>
<p>This attribute is also specific to WSDL 2.0's SOAP binding
extension. This specifies the SOAP 1.2 fault code that will cause
this fault message to be sent. If desired, a list of subcodes can
also be specified using the optional <code>wsoap:subcodes</code>
attribute.</p>
</dd>
</dl>
</div>
</div>
<div class="div3">
<h4><a name="basics-service" id="basics-service"></a>2.1.6 Defining
a Service</h4>
<p>Now that our binding has specified <em>how</em> messages will be
transmitted, we are ready to specify <em>where</em> the service can
be accessed, by use of the <code>service</code> element.</p>
<p>A WSDL 2.0 <em>service</em> specifies a single interface that
the service will support, and a list of <em>endpoint</em> locations
where that service can be accessed. Each endpoint must also
reference a previously defined binding to indicate what protocols
and transmission formats are to be used at that endpoint. A service
is only permitted to have one interface. (See <a href=
"#adv-multiple-docs-describing-same-service"><strong>5.4 Multiple
Interfaces for the Same Service</strong></a> for further discussion
of this limitation.)</p>
<p>Here is a definition for our GreatH service.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-initial-service" id=
"example-initial-service"></a><em><span>Example 2-6.</span> GreatH
Service Definition</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description 
    xmlns="http://www.w3.org/ns/wsdl"
    targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
    xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
    xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
    xmlns:wsoap= "http://www.w3.org/ns/wsdl/soap"
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"&gt;
  . . .

  &lt;types&gt;
    . . .
  &lt;/types&gt;
  
  &lt;interface  name = "reservationInterface" &gt;
    . . .
  &lt;/interface&gt;

  &lt;binding name="reservationSOAPBinding" 
          interface="tns:reservationInterface"
        . . . &gt;
    . . .
  &lt;/binding&gt;

  &lt;service name="reservationService" 
       interface="tns:reservationInterface"&gt;

     &lt;endpoint name="reservationEndpoint" 
               binding="tns:reservationSOAPBinding"
               address ="http://greath.example.com/2004/reservation"/&gt;
        
  &lt;/service&gt;
  
&lt;/description&gt;
</pre></div>
</div>
<div class="div4">
<h5><a name="example-initial-service-explanation" id=
"example-initial-service-explanation"></a>2.1.6.1 Explanation of
Example</h5>
<dl>
<dt class="label"><code>&lt;service
name="reservationService"</code></dt>
<dd>
<p>This defines a name for this service, which must be unique among
service names in the WSDL 2.0 target namespace. The name attribute
is required. It allows URIs to be created that identify components
in WSDL 2.0 description. (See <em>WSDL 2.0 Core Language</em>
[<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>] appendix C
<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626/#wsdl-iri-references">
IRI References for WSDL 2.0 constructs</a>.)</p>
</dd>
<dt class="label">
<code>interface="tns:reservationInterface"&gt;</code></dt>
<dd>
<p>This specifies the name of the previously defined interface that
these service endpoints will support.</p>
</dd>
<dt class="label"><code>&lt;endpoint
name="reservationEndpoint"</code></dt>
<dd>
<p>This defines an endpoint for the service, and a name for this
endpoint, which must be unique within this service.</p>
</dd>
<dt class="label">
<code>binding="tns:reservationSOAPBinding"</code></dt>
<dd>
<p>This specifies the name of the previously defined binding to be
used by this endpoint.</p>
</dd>
<dt class="label"><code>address
="http://greath.example.com/2004/reservation"/&gt;</code></dt>
<dd>
<p>This specifies the physical address at which this service can be
accessed using the binding specified by the <code>binding</code>
attribute.</p>
</dd>
</dl>
<p>That's it! Well, almost.</p>
</div>
</div>
<div class="div3">
<h4><a name="basics-documentation" id=
"basics-documentation"></a>2.1.7 Documenting the Service</h4>
<p>As we have seen, a WSDL 2.0 document is inherently only a
<em>partial</em> description of a service. Although it captures the
basic mechanics of interacting with the service -- the message
types, transmission protocols, service location, etc. -- in
general, additional documentation will need to explain other
application-level requirements for its use. For example, such
documentation should explain the purpose and use of the service,
the meanings of all messages, constraints on their use, and the
sequence in which operations should be invoked.</p>
<p>The <code>documentation</code> element allows the WSDL 2.0
author to include some human-readable documentation inside a WSDL
2.0 document. It is also a convenient place to reference any
additional external documentation that a client developer may need
in order to use the service. It can appear in a number of places in
a WSDL 2.0 document (see <a href=
"#wsdl-infoset-diagram"><strong>2.2.1 WSDL 2.0
Infoset</strong></a>), though in this example we have only
demonstrated its use at the beginning.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-initial-documentation" id=
"example-initial-documentation"></a><em><span>Example 2-7.</span>
Documenting the GreatH Service</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description 
    . . . &gt;

  &lt;documentation&gt;
    This document describes the GreatH Web service.  Additional 
    application-level requirements for use of this service -- 
    beyond what WSDL 2.0 is able to describe -- are available 
    at http://greath.example.com/2004/reservation-documentation.html
  &lt;/documentation&gt;
  . . .  
&lt;/description&gt;
</pre></div>
</div>
<div class="div4">
<h5><a name="example-initial-documentation-explanation" id=
"example-initial-documentation-explanation"></a>2.1.7.1 Explanation
of Example</h5>
<dl>
<dt class="label"><code>&lt;documentation&gt;</code></dt>
<dd>
<p>This element is optional, but a good idea to include. It can
contain arbitrary mixed content.</p>
</dd>
<dt class="label"><code>at
http://greath.example.com/2004/reservation-documentation.html</code></dt>
<dd>
<p>The most important thing to include is a pointer to any
additional documentation that a client developer would need in
order to use the service.</p>
</dd>
</dl>
<p>This completes our presentation of the GreatH example. In the
following sections, we will move on to look into more details of
various aspects of WSDL 2.0 specification.</p>
</div>
</div>
</div>
<div class="div2">
<h3><a name="wsdl-xml-representation" id=
"wsdl-xml-representation"></a>2.2 WSDL 2.0 Infoset, Schema and
Component Model</h3>
<p>In computer science theory, a language consists of a (possibly
infinite) set of sentences, and each sentence is a finite string of
literal symbols or characters. A language specification must
therefore define the set of sentences in that language, and, to be
useful, it should also indicate the meaning of each sentence.
Indeed, this is the purpose of the WSDL 2.0 specification.</p>
<p>However, instead of defining WSDL 2.0 in terms of literal
symbols or characters, to avoid dependency on any particular
character encoding, WSDL 2.0 is defined in terms of the <em>XML
Infoset</em> [<cite><a href="#XMLInfoSet">XML Information
Set</a></cite>]. Specifically, a <em>WSDL 2.0 document</em>
consists of a <code>description</code> element information item (in
the XML Infoset) that conforms to the WSDL 2.0 specification. In
other words, a sentence in the WSDL 2.0 language is a
<code>description</code> element information item that obeys the
additional constraints spelled out in the WSDL 2.0
specification.</p>
<p>Since an XML Infoset can be created from more than one physical
document, a WSDL 2.0 document does not necessarily correspond to a
single <em>physical</em> document: the word "document" is used
figuratively, for convenience. Furthermore, since WSDL 2.0 provides
<code>import</code> and <code>include</code> mechanisms, a WSDL 2.0
document may reference other WSDL 2.0 documents to facilitate
convenient organization or reuse. In such cases, the meaning of the
including or importing document as a whole will depend (in part) on
the meaning of the included or imported document.</p>
<p>The XML Infoset uses terms like "element information item" and
"attribute information item". Unfortunately, those terms are rather
lengthy to repeat often. Thus, for convenience, this primer often
uses the terms "element" and "attribute" instead, as a shorthand.
It should be understood, however, that since WSDL 2.0 is based on
the XML Infoset, we really mean "element information item" and
"attribute information item", respectively.</p>
<div class="div3">
<h4><a name="wsdl-infoset-diagram" id=
"wsdl-infoset-diagram"></a>2.2.1 WSDL 2.0 Infoset</h4>
<p>The following diagram gives an overview of the XML Infoset for a
WSDL 2.0 document.</p>
<div class="figure" style="text-align: center"><br />
<img src="images/WSDL20InfosetModel.png" alt=
"WSDL 2.0 Infoset Diagram" />
<p style="text-align:left"><em><span>Figure 2-1.</span> WSDL 2.0
Infoset Diagram</em></p>

<br /></div>
</div>
<div class="div3">
<h4><a name="wsdl-schema" id="wsdl-schema"></a>2.2.2 WSDL 2.0
Schema</h4>
<p>The WSDL 2.0 specification supplies a <a href=
"http://www.w3.org/ns/wsdl">normative WSDL 2.0 schema</a>, defined
in [<cite><a href="#XMLSchemaP1">XML Schema Structures</a></cite>],
which can be used as an aid in validating WSDL 2.0 documents. We
say "as an aid" here because WSDL 2.0 specification [<cite><a href=
"#WSDL-PART1">WSDL 2.0 Core</a></cite>] often provides further
constraints to the WSDL 2.0 schema. In addition to being valid with
the normative schema, a WSDL 2.0 document must also follow all the
constraints defined by the WSDL 2.0 specification.</p>
<div class="div4">
<h5><a name="element-order" id="element-order"></a>2.2.2.1 WSDL 2.0
Element Ordering</h5>
<p>This section gives an example of how WSDL 2.0 specification
constrains the WSDL 2.0 schema about the ordering of top WSDL 2.0
elements.</p>
<p>Although the WSDL 2.0 schema does not indicate the required
ordering of elements, the WSDL 2.0 specification (WSDL 2.0 Part 1
[<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>] section
"<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#Description_XMLRep">XML
Representation of Description Component</a>") clearly states a set
of constraints about how the child elements of the
<code>description</code> element should be ordered. Thus, the order
of the WSDL 2.0 elements matters, even though the WSDL 2.0 schema
does not capture this constraint.</p>
<p>The following is a pseudo-content model of
<code>description</code>.</p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;<strong>description</strong>&gt;
  &lt;documentation /&gt;?
  [ &lt;import /&gt; | &lt;include /&gt; ]*
  &lt;types /&gt;?
  [ &lt;interface /&gt; | &lt;binding /&gt; | &lt;service /&gt; ]*
&lt;/<strong>description</strong>&gt;
</pre></div>
<p>In other words, the children elements of the
<code>description</code> element should be ordered as follows:</p>
<ul>
<li>
<p>An optional <code>documentation</code> comes first, if
present.</p>
</li>
<li>
<p>then comes zero or more elements from among the following, in
any order:</p>
<ul>
<li>
<p><code>include</code></p>
</li>
<li>
<p><code>import</code></p>
</li>
<li>
<p>extensions</p>
</li>
</ul>
</li>
<li>
<p>An optional <code>types</code> follows</p>
</li>
<li>
<p>Zero or more elements from among the following, in any
order:</p>
<ul>
<li>
<p><code>interface</code></p>
</li>
<li>
<p><code>binding</code></p>
</li>
<li>
<p><code>service</code></p>
</li>
<li>
<p>extensions.</p>
</li>
</ul>
</li>
</ul>
<p>Note the term "extension" is used above as a convenient way to
refer to namespace-qualified extension elements. The namespace name
of such extension elements must not
be"http://www.w3.org/ns/wsdl".</p>
</div>
</div>
<div class="div3">
<h4><a name="component-model" id="component-model"></a>2.2.3 WSDL
2.0 Component Model</h4>
<p>The WSDL 2.0 Infoset model above illustrates the required
structure of a WSDL 2.0 document, using the XML Infoset. However,
the WSDL 2.0 language also imposes many semantic constraints over
and above structural conformance to this XML Infoset. In order to
precisely describe these constraints, and as an aid in precisely
defining the meaning of each WSDL 2.0 document, the WSDL 2.0
specification defines a <em>component model</em> as an additional
layer of abstraction above the XML Infoset. Constraints and meaning
are defined in terms of this component model, and the definition of
each component includes a mapping that specifies how values in the
component model are derived from corresponding items in the XML
Infoset. The following diagram gives an overview of the WSDL 2.0
components and their containment hierarchy.</p>
<div class="figure" style="text-align: center"><br />
<img src="images/WSDL20Components.png" alt=
"WSDL 2.0 Components Containment hierarchy" />
<p style="text-align:left"><em><span>Figure 2-2.</span> WSDL 2.0
Components Containment hierarchy</em></p>

<br /></div>
<p>In general, the WSDL 2.0 component model parallels the structure
of the required XML Infoset illustrated above. For example, the
<em>Description</em>, <em>Interface</em>, <em>Binding</em>,
<em>Service</em> and <em>Endpoint</em> <em>components</em>
correspond to the <code>description</code>, <code>interface</code>,
<code>binding</code>, <code>service</code>, and
<code>endpoint</code> element information items, respectively.
Since WSDL 2.0 relies heavily on the component model to convey the
meaning of the constructs in the WSDL 2.0 language, you can think
of the Description component as representing the meaning of the
<code>description</code> element information item, and hence, it
represents the meaning of the WSDL 2.0 document as a whole.</p>
<p>Furthermore, each of these components has <em>properties</em>
whose values are (usually) derived from the element and attribute
information item children of those element information items. For
example, the Service component corresponds to the
<code>service</code> element information item, so the Service
component has an {endpoints} property whose value is a set of
Endpoint components corresponding to the <code>endpoint</code>
element information item children of that <code>service</code>
element information item. (Whew!)</p>
<div class="div4">
<h5><a name="import-component" id="import-component"></a>2.2.3.1
WSDL 2.0 Import and Include</h5>
<p>The WSDL 2.0 component model is particularly helpful in defining
the meaning of <code>import</code> and <code>include</code>
elements. The <code>include</code> element allows you to assemble
the contents of a given WSDL 2.0 namespace from several WSDL 2.0
documents that define components for that namespace. The components
defined by a given WSDL 2.0 document consist of those whose
definitions are contained in the document and those that are
defined by any WSDL 2.0 documents that are included in it via the
<code>include</code> element. The effect of the
<code>include</code> element is cumulative so that if document A
includes document B and document B includes document C, then the
components defined by document A consist of those whose definitions
are contained in documents A, B, and C.</p>
<p>In contrast, the <code>import</code> element does not define any
components. Instead, the <code>import</code> element declares that
the components whose definitions are contained in a WSDL 2.0
document for a given WSDL 2.0 namespace refer to components that
belong to a different WSDL 2.0 namespace. If a WSDL 2.0 document
contains definitions of components that refer to other namespaces,
then those namespaces must be declared via an <code>import</code>
element. The <code>import</code> element also has an optional
<code>location</code> attribute that is a hint to the processor
where the definitions of the imported namespace can be found.
However, the processor may find the definitions by other means, for
example, by using a catalog.</p>
<p>After processing any <code>include</code> elements and locating
the components that belong to any imported namespaces, the WSDL 2.0
component model for a WSDL 2.0 document will contain a set of
components that belong to the document's WSDL 2.0 namespace and any
imported namespaces. These components will refer to each other,
usually via QName references. A WSDL 2.0 document is invalid if any
component reference cannot be resolved, whether or not the
referenced component belongs to the same or a different
namespace.</p>
<p>We will cover a lot more about how to use WSDL 2.0 import and
include in <a href="#adv-import-and-authoring"><strong>3.1
Importing WSDL</strong></a></p>
</div>
</div>
</div>
<div class="div2">
<h3><a name="more-types" id="more-types"></a>2.3 More on Message
Types</h3>
<p>Message types may be defined in various schema languages. In
this primer, we will only focus on the use of XML Schema
[<cite><a href="#XMLSchemaP1">XML Schema Structures</a></cite>]
since it's natively supported by WSDL 2.0. Message types defined in
other languages may be introduced into a WSDL 2.0
<code>description</code> via extensions, see the W3C notes
[<cite><a href="#altschemalangs">Alternative Schema Languages
Support</a></cite>] for more details.</p>
<p>The following is the XML syntax for the <code>wsdl:types</code>
element:</p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;description&gt;
  &lt;<strong>types</strong>&gt;
    &lt;documentation /&gt;*
    [ &lt;xs:import namespace="<em>xs:anyURI</em>" schemaLocation="<em>xs:anyURI</em>"? /&gt; |
      &lt;xs:schema targetNamespace="<em>xs:anyURI</em>" /&gt; |
      <em>other extension elements</em> ]*
  &lt;/<strong>types</strong>&gt;
&lt;/description&gt;
</pre></div>
<p>There are two ways to make XML Schema message definitions
visible, or in other words, available for reference by QName (see
WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0
Core</a></cite>] "<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#qnameres">QName
Resolution</a>") in a WSDL 2.0 document: inlining or importing.
Inlining is to put the schema definitions directly within an
<code>xs:schema</code> element under <code>types</code>. Importing
is to have the schema defined in a separate document and then bring
it into the WSDL definition by using <code>xs:import</code>
directly under <code>types</code>.</p>
<p>In the following sections, we will provide examples for the
different mechanisms.</p>
<div class="div3">
<h4><a name="more-types-schema-inline" id=
"more-types-schema-inline"></a>2.3.1 Inlining XML Schema</h4>
<p>We have already seen an example of using inlined schema
definitions in section <a href="#basics-types"><strong>2.1.3
Defining Message Types</strong></a>. When XML Schema is inlined
directly in a WSDL 2.0 document, it uses the existing top-level
<code>xs:schema</code> element defined by XML Schema to do so, as
though a schema file had been copied and pasted into the
<code>types</code> element. The schema components defined in the
inlined schema are then available to the containing WSDL 2.0
<code>description</code> for reference by QName. For instance, in
<a href="#example-initial">Example 2-1</a>, the input message of
the interface operation "opCheckAvailability" is defined by the
"ghns:checkAvailability" element in the inlined schema.</p>
</div>
<div class="div3">
<h4><a name="more-types-schema-import" id=
"more-types-schema-import"></a>2.3.2 Importing XML Schema</h4>
<p>XML Schema components can be defined in separate schema files
and be made available to a WSDL2.0 <code>description</code> by
using <code>xs:import</code> directly under <code>types</code>.</p>
<p>There are many cases where one would prefer having schema
definitions in separate schema files. One reason is the reusability
of the schema definitions. Inlined schema definitions are only
available to the containing WSDL 2.0 <code>description</code>.
Although WSDL 2.0 provides a <code>wsdl:import</code> mechanism for
importing other WSDL files, schema definitions inlined in an
imported WSDL document are NOT automatically made available to the
importing WSDL 2.0 document, even though other WSDL 2.0 components
(such as Interfaces, Bindings, etc.) do become available.
Therefore, if one wishes to share schema definitions across several
WSDL 2.0 <code>description</code>s, these schema definitions should
instead be placed in separate XML Schema documents and imported
into each WSDL 2.0 <code>description</code> using
<code>xs:import</code> directly under <code>types</code>.</p>
<p>Let's see an example. Assuming the message types in <a href=
"#example-initial-types">Example 2-3</a> are defined in a separate
schema file named
"http://greath.example.com/2004/schemas/resSvc.xsd" with a target
namespace "http://greath.example.com/2004/schemas/resSvc", the
schema definition can then be brought into the WSDL 2.0
<code>description</code> using <code>xs:import</code>. Note that
only components in the imported namespace
"http://greath.example.com/2004/schemas/resSvc" are available for
reference in the WSDL 2.0 document.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-schema-import" id=
"example-schema-import"></a><em><span>Example 2-8.</span>
<code>xs:import</code>ed Message Definitions that Are Visible to
the Containing WSDL 2.0 Description</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description xmlns="http://www.w3.org/ns/wsdl"
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
. . . &gt;
. . .

&lt;types&gt;
        &lt;xs:import namespace="http://greath.example.com/2004/schemas/resSvc" 
                schemaLocation= "http://greath.example.com/2004/schemas/resSvc.xsd"/&gt;  
&lt;/types&gt;

. . .
&lt;/description&gt;
</pre></div>
</div>
<p>It's important to note that <code>xs:import</code> used directly
under <code>wsdl:types</code> has been given a different visibility
than <code>xs:import</code> used inside an inlined schema. An
inlined schema may use native XML schema <code>xs:import</code> to
bring in external schema definitions that are in different
namespaces; However, though this is the schema importing mechanism
recommended for WSDL 1.1 in <a href=
"http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#WSDL_and_Schema_Import">
WS-I Basic Profile</a>, according to XML Schema specification, such
enclosed message definitions are only visible to the importing
schema (in this case, the inlined schema). They are not visible to
the containing WSDL 2.0 <code>description</code>.</p>
<p>If we change <a href="#example-schema-import">Example 2-8</a> to
use XML Schema's native <code>xs:import</code> element in an
inlined schema, the schema components defined in the namespace
http://greath.example.com/2004/schemas/resSvc are not available to
our example WSDL 2.0 definition any more.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-schema-import1" id=
"example-schema-import1"></a><em><span>Example 2-9.</span>
<code>xs:import</code>ed Message Definitions in Inlined Schema Are
Not Visible to the Containing WSDL 2.0 Description</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description xmlns="http://www.w3.org/ns/wsdl"
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
. . . &gt;
. . .

&lt;types&gt;
        &lt;xs:schema targetNamespace="http://greath.example.com/2004/schemas/resSvcWrapper"&gt;
                &lt;xs:import namespace="http://greath.example.com/2004/schemas/resSvc" 
                schemaLocation= "http://greath.example.com/2004/schemas/resSvc.xsd"/&gt;  
        &lt;/xs:schema&gt;
&lt;/types&gt;

. . .
&lt;/description&gt;
</pre></div>
</div>
<p>Of course, an inlined XML schema may also use XML Schema's
native <code>xs:include</code> element to refer to schemas defined
in separate files when the included schema has no namespace or has
the same namespace as the including schema. In this case, according
to XML Schema, the included schema components become a part of the
including schema as though they had been copied and pasted into the
including schema. Hence, the included schema components are also
available to the containing WSDL 2.0 <code>description</code> for
reference by QName.</p>
<p>The following example has the same effect as <a href=
"#example-initial-types">Example 2-3</a>:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-schema-import2" id=
"example-schema-import2"></a><em><span>Example 2-10.</span>
<code>xs:included</code> Message Definitions in Inlined Schema Are
Visible to the Containing WSDL 2.0 Description</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description xmlns="http://www.w3.org/ns/wsdl"
targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 
xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc"
xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
. . . &gt;
. . .

&lt;types&gt;
        &lt;xs:schema targetNamespace="http://greath.example.com/2004/schemas/resSvc"&gt;
                &lt;xs:include schemaLocation= "http://greath.example.com/2004/schemas/resSvc.xsd"/&gt;  
        &lt;/xs:schema&gt;
&lt;/types&gt;

. . .
&lt;/description&gt;
</pre></div>
</div>
</div>
<div class="div3">
<h4><a name="more-types-import-include-summary" id=
"more-types-import-include-summary"></a>2.3.3 Summary of Import and
Include Mechanisms</h4>
<p>So far we have briefly covered both WSDL import and include and
schema import and include. The following table summarizes the
similarities and differences between the WSDL 2.0 and XML Schema
<code>include</code> and <code>import</code> mechanisms. We will
talk a lot more about importing mechanisms in <a href=
"#adv-import-and-authoring"><strong>3.1 Importing WSDL</strong></a>
and <a href="#adv-multiple-inline-schemas"><strong>3.2 Importing
Schemas</strong></a></p>
<a name="imin" id="imin"></a>
<table border="1">
<caption>Table 2-1. Summary of Import and Include
Mechanisms</caption>
<thead>
<tr>
<th rowspan="1" colspan="1">Mechanism</th>
<th rowspan="1" colspan="1">Object</th>
<th rowspan="1" colspan="1">Meaning</th>
<th rowspan="1" colspan="1">Visibility of Schema Components</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="1" colspan="1">wsdl:import</td>
<td rowspan="1" colspan="1">WSDL 2.0 Namespace</td>
<td rowspan="1" colspan="1">Declare that WSDL 2.0 components refer
to WSDL 2.0 components from a DIFFERENT targetNamespace.</td>
<td rowspan="1" colspan="1">XML Schema Components in the imported
<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#component-Description">
Description</a> component are NOT visible to the containing
<code>description</code>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">wsdl:include</td>
<td rowspan="1" colspan="1">WSDL 2.0 Document</td>
<td rowspan="1" colspan="1">Merge Interface, Binding and Service
components from another WSDL 2.0 document that has the SAME
targetNamespace.</td>
<td rowspan="1" colspan="1">XML Schema components in the included
<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#component-Description">
Description</a> component's {<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#property-Description.elementdeclarations">element
declarations</a>} and {<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#property-Description.typedefinitions">type
definitions</a>} properties are visible to the containing
<code>description</code>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">wsdl:types/ xs:import</td>
<td rowspan="1" colspan="1">XML Schema Namespace</td>
<td rowspan="1" colspan="1">Declare that XML Schema components
refer to XML Schema components from a DIFFERENT
targetNamespace.</td>
<td rowspan="1" colspan="1">XML Schema components in the imported
namespace are visible to the containing
<code>description</code>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">wsdl:types/ xs:schema/xs:import</td>
<td rowspan="1" colspan="1">XML Schema Namespace</td>
<td rowspan="1" colspan="1">Declare that XML Schema components
refer to XML Schema components from a DIFFERENT
targetNamespace.</td>
<td rowspan="1" colspan="1">XML Schema components in the imported
namespace are NOT visible to the containing
<code>description</code>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">wsdl:types/ xs:schema/xs:include</td>
<td rowspan="1" colspan="1">XML Schema Document</td>
<td rowspan="1" colspan="1">Merge XML Schema components from
another XML Schema document that has the SAME or NO
targetNamespace.</td>
<td rowspan="1" colspan="1">XML Schema components in the included
document are visible to the containing
<code>description</code>.</td>
</tr>
</tbody>
</table>

<br /></div>
</div>
<div class="div2">
<h3><a name="more-interfaces" id="more-interfaces"></a>2.4 More on
Interfaces</h3>
<p>We previously mentioned that a WSDL 2.0 interface is basically a
set of operations. However, there are some additional capabilities
that we have not yet covered. First, let's review the syntax for
the <code>interface</code> element.</p>
<div class="div3">
<h4><a name="more-interfaces-interfaces" id=
"more-interfaces-interfaces"></a>2.4.1 Interface Syntax</h4>
<p>Below is the XML syntax summary of the <code>interface</code>
element, simplified by omitting optional
<code>&lt;documentation&gt;</code> elements:</p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;description targetNamespace="<em>xs:anyURI</em>" &gt;

  . . .
  &lt;interface name="<em>xs:NCName</em>" 
          extends="<em>list of xs:QName</em>"? 
          styleDefault="<em>list of xs:anyURI</em>"? &gt;

    &lt;fault name="<em>xs:NCName</em>" 
            element="<em>xs:QName</em>"? &gt;
    &lt;/fault&gt;*

    &lt;operation name="<em>xs:NCName</em>" 
            pattern="<em>xs:anyURI</em>" 
            style="<em>list of xs:anyURI</em>"? 
            wsdlx:safe="<em>xs:boolean</em>"? &gt;

      &lt;input messageLabel="<em>xs:NCName</em>"? 
            element="<em>union of xs:QName, xs:Token</em>"? &gt;
      &lt;/input&gt;*

      &lt;output messageLabel="<em>xs:NCName</em>"? 
            element="<em>union of xs:QName, xs:Token</em>"? &gt;
      &lt;/output&gt;*

      &lt;infault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? &gt; &lt;/infault&gt;*

      &lt;outfault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? &gt; &lt;/outfault&gt;*

    &lt;/operation&gt;*

  &lt;/interface&gt;*
  . . .

&lt;/description&gt;
  
</pre></div>
<p>The <code>interface</code> element has two optional attributes:
<code>styleDefault</code> and <code>extends</code>. The
<code>styleDefault</code> attribute can be used to define a default
value for the <code>style</code> attributes of all operations under
this interface (see WSDL 2.0 Part 1 "<a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#Interface_styleDefault_attribute">styleDefault
attribute information item</a>"). The <code>extends</code>
attribute is for inheritance, and is explained next.</p>
</div>
<div class="div3">
<h4><a name="more-interfaces-inheritance" id=
"more-interfaces-inheritance"></a>2.4.2 Interface Inheritance</h4>
<p>The optional <code>extends</code> attribute allows an interface
to extend or inherit from one or more other interfaces. In such
cases the interface contains the operations of the interfaces it
extends, along with any operations it defines directly. Two things
about extending interfaces deserve some attention.</p>
<p>First, an inheritance loop (or infinite recursion) is
prohibited: the interfaces that a given interface extends must NOT
themselves extend that interface either directly or indirectly.</p>
<p>Second, we must explain what happens when operations from two
different interfaces have the same target namespace and operation
name. There are two cases: either the component models of the
operations are the same, or they are different. If the component
models are the same (per the component comparison algorithm defined
in WSDL 2.0 Part 1 [<cite><a href="#WSDL-PART1">WSDL 2.0
Core</a></cite>] " <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#compequiv">Equivalence
of Components</a> ") then they are considered to be the same
operation, i.e., they are collapsed into a single operation, and
the fact that they were included more than once is not considered
an error. (For operations, component equivalence basically means
that the two operations have the same set of attributes and
descendants.) In the second case, if two operations have the same
name in the same WSDL 2.0 target namespace but are not equivalent,
then it is an error. For the above reason, it is considered good
practice to ensure that all operations within the same target
namespace are named uniquely.</p>
<p>Finally, since faults can also be defined as children of the
<code>interface</code> element (as described in the following
sections), the same name-collision rules apply to those
constructs.</p>
<p>Let's say the GreatH hotel wants to maintain a standard message
log operation for all received messages. It wants this operation to
be reusable across the whole reservation system, so each service
will send out, for potential use of a logging service, the content
of each message it receives together with a timestamp and the
originator of the message. One way to meet such requirement is to
define the log operation in an interface which can be inherited by
other interfaces. Assuming a <code>messageLog</code> element is
already defined in the ghns namespace with the required content,
the inheritance use case is illustrated in the following example.
As a result of the inheritance, the
<code>reservationInterface</code> now contains two operations:
<code>opCheckAvailability</code> and <code>opLogMessage</code></p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-faults" id="example-faults"></a><em><span>Example
2-11.</span> Interface Inheritance</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
                                        
&lt;description ...&gt;
        ...
        &lt;interface  name = "messageLogInterface" &gt;
                                
                &lt;operation name="opLogMessage" 
                                pattern="http://www.w3.org/ns/wsdl/out-only"&gt;
                        &lt;output messageLabel="out" 
                                element="ghns:messageLog" /&gt;
                &lt;/operation&gt;

        &lt;/interface&gt;

        &lt;interface  name="reservationInterface" <strong>extends</strong>="tns:messageLogInterface" &gt;
   
                &lt;operation name="opCheckAvailability" 
                                pattern="http://www.w3.org/ns/wsdl/in-out"
                                style="http://www.w3.org/ns/wsdl/style/iri"
                                wsdlx:safe = "true"&gt;
                        &lt;input messageLabel="In" 
                                element="ghns:checkAvailability" /&gt;
                        &lt;output messageLabel="Out" 
                                element="ghns:checkAvailabilityResponse" /&gt;
                        &lt;outfault ref="tns:invalidDataFault" messageLabel="Out"/&gt;

                &lt;/operation&gt;
        &lt;/interface&gt;
        ...
&lt;/description&gt;
</pre></div>
</div>
<p>Now let's have a look at the element children of
<code>interface</code>, beginning with <code>fault</code>.</p>
</div>
<div class="div3">
<h4><a name="more-interfaces-faults" id=
"more-interfaces-faults"></a>2.4.3 Interface Faults</h4>
<p>The <code>fault</code> element is used to declare faults that
may occur during execution of operations of an interface. They are
declared directly under <code>interface</code>, and referenced from
operations where they apply, in order to permit reuse across
multiple operations.</p>
<p>Faults are very similar to messages and can be viewed as a
special kind of message. Both faults and messages may carry a
payload that is normally described by an element declaration.
However, WSDL 2.0 treats faults and messages slightly differently.
The messages of an operation directly refer to their element
declaration, however the faults of an operation indirectly refer to
their element declaration via a fault element that is defined on
the interface.</p>
<p>The reason for defining faults at the interface level is to
allow their reuse across multiple operations. This design is
especially beneficial when bindings are defined, since in binding
extensions like SOAP there is additional information that is
associated with faults. In the case of SOAP, faults have codes and
subcodes in addition to a payload. By defining faults at the
interface level, common codes and subcodes can be associated with
them, thereby ensuring consistency across all operations that use
the faults</p>
<p>The <code>fault</code> element has a required <code>name</code>
attribute that must be unique within the parent
<code>interface</code> element, and permits it to be referenced
from operation declarations. The optional <code>element</code>
attribute can be used to indicate a schema for the content or
payload of the fault message. Its value should be the QName of a
global element defined in the <code>types</code> section. Please
note that when other type systems are used to define the schema for
a fault message, additional attributes may need to be defined via
WSDL 2.0's attribute extension mechanism to allow the schema to be
associated with the fault.</p>
</div>
<div class="div3">
<h4><a name="more-interfaces-operations" id=
"more-interfaces-operations"></a>2.4.4 Interface Operations</h4>
<p>As shown earlier, the <code>operation</code> element is used to
indicate an operation supported by the containing interface. It
associates message schemas with a message exchange pattern (MEP),
in order to abstractly describe a simple interaction with a Web
service.</p>
<div class="div4">
<h5><a name="more-interfaces-op-attr" id=
"more-interfaces-op-attr"></a>2.4.4.1 Operation Attributes</h5>
<p>An <code>operation</code> has two required attributes and one
optional attribute:</p>
<ul>
<li>
<p>A required <code>name</code> attribute, as seen already, which
must be unique within the interface.</p>
</li>
<li>
<p>A required <code>pattern</code> attribute whose value must be an
absolute URI that identifies the desired MEP for the
<code>operation</code>. MEPs are further explained in <a href=
"#more-interfaces-meps"><strong>2.4.4.3 Understanding Message
Exchange Patterns (MEPs)</strong></a>.</p>
</li>
<li>
<p>An optional <code>style</code> attribute whose value is a list
of absolute URIs. Each URI identifies a certain set of rules that
were followed in defining this <code>operation</code>. It is an
error if a particular style is indicated, but the associated rules
are not followed. [<cite><a href="#WSDL-PART2">WSDL 2.0
Adjuncts</a></cite>] defines a set of styles, including</p>
<ul>
<li>
<p>RPC Style. The RPC style is selected when the <code>style</code>
is assigned the value http://www.w3.org/ns/wsdl/rpc. It places
restrictions for Remote Procedure Call-types of interactions.</p>
</li>
<li>
<p>IRI Style. The IRI style is selected when the <code>style</code>
is assigned the value http://www.w3.org/ns/wsdl/style/iri. It
places restrictions on message definitions so they may be
serialized into something like HTTP URL encoded.</p>
</li>
<li>
<p>The Multipart style. The Multipart style is selected when the
<code>style</code> is assigned the value
http://www.w3.org/ns/wsdl/style/multipart. In the HTTP binding, for
XForms clients, a message must be defined following the Multipart
style and serialized as "Multipart/form-data".</p>
</li>
</ul>
<p>You can find more details of these WSDL 2.0 predefined styles.
Section <a href="#adv-RPCstyle"><strong>4.3 RPC Style</strong></a>
provides an example of using the RPC <code>style</code>.
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] provides
examples for the IRI style and Multipart style.</p>
</li>
</ul>
<p>Note that [<cite><a href="#WSDL-PART2">WSDL 2.0
Adjuncts</a></cite>] provides a predefined extension for indicating
operation safety. The <code>wsdlx:safe</code> global attribute
whose value is a boolean can be used with an operation to indicate
whether the operation is asserted to be "safe" (as defined in
Section 3.5 of the Web Architecture [<cite><a href="#webarch">Web
Architecture</a></cite>]) for clients to invoke. In essence, a safe
operation is any operation that does not give the client any new
obligations. For example, an operation that permits the client to
check prices on products typically would not obligate the client to
buy those products, and thus would be safe, whereas an operation
for purchasing products would obligate the client to pay for the
products that were ordered, and thus would not be safe.</p>
<p>An operation should be marked safe (by using the
<code>wsdlx:safe</code> and by setting its value to "true") if it
meets the criteria for a safe interaction defined in Section 3.5 of
the Web Architecture [<cite><a href="#webarch">Web
Architecture</a></cite>], because this permits the infrastructure
to perform efficiency optimizations, such as pre-fetch, re-fetch
and caching.</p>
<p>The default value of this attribute is false. If it is false or
is not set, then no assertion is made about the safety of the
operation; thus the operation may or may not be safe.</p>
</div>
<div class="div4">
<h5><a name="id2295836" id="id2295836"></a>2.4.4.2 Operation
Message References</h5>
<p>An <code>operation</code> will also have <code>input</code>,
<code>output</code>,<code>infault</code>, and/or
<code>outfault</code> element children that specify the ordinary
and fault message types to be used by that operation. The MEP
specified by the <code>pattern</code> attribute determines which of
these elements should be included, since each MEP has placeholders
for the message types involved in its pattern.</p>
<p>Since operations were already discussed in <a href=
"#basics-interface"><strong>2.1.4 Defining an
Interface</strong></a>, this section will merely comment on
additional capabilities that were not previously explained.</p>
<div class="div5">
<h6><a name="id2295901" id="id2295901"></a>2.4.4.2.1 The
messageLabel Attribute</h6>
<p>The <code>messageLabel</code> attribute of the
<code>input</code> and <code>output</code> elements is optional. It
is not necessary to explicitly set the <code>messageLabel</code>
when the MEP in use is one of the eight MEPs predefined in WSDL 2.0
Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]
and it has only one message with a given direction.</p>
</div>
<div class="div5">
<h6><a name="id2295952" id="id2295952"></a>2.4.4.2.2 The element
Attribute</h6>
<p>The <code>element</code> attribute of the <code>input</code> and
<code>output</code> elements is used to specify the message content
schema (aka payload schema) when the content model is defined using
XML Schema. As we have seen already, it can specify the QName of an
element schema that was defined in the <code>types</code> section.
However, alternatively it can specify one of the following
tokens:</p>
<dl>
<dt class="label"><code>#any</code></dt>
<dd>
<p>The message content is any single element.</p>
</dd>
<dt class="label"><code>#none</code></dt>
<dd>
<p>There is no message content, i.e., the message payload is
empty.</p>
</dd>
<dt class="label"><code>#other</code></dt>
<dd>
<p>The message content is described by a non-XML type system.
Extension attributes specify the type.</p>
</dd>
</dl>
<p>The <code>element</code> attribute is also optional. If it is
not specified, then the message content is described by a non-XML
type system.</p>
<p>Note that there are situations that the information conveyed in
the <code>element</code> attribute is not sufficient for a service
implementation to uniquely identify an incoming message and
dispatch it to an appropriate operation. In such situations,
additional means may be required to aid identifying an incoming
message. See <a href="#adv-message-dispatch"><strong>5.1 Enabling
Easy Message Dispatch</strong></a> for more detail.</p>
</div>
<div class="div5">
<h6><a name="id2296126" id="id2296126"></a>2.4.4.2.3 Multiple
infault or outfault Elements</h6>
<p>When <code>infault</code> and/or <code>outfault</code> occur
multiple times within an <code>operation</code>, they define
alternative fault messages.</p>
</div>
</div>
<div class="div4">
<h5><a name="more-interfaces-meps" id=
"more-interfaces-meps"></a>2.4.4.3 Understanding Message Exchange
Patterns (MEPs)</h5>
<p>WSDL 2.0 message exchange patterns (MEPs) are used to define the
sequence and cardinality of the abstract messages in an operation.
By design, WSDL 2.0 MEPs are abstract. First of all, they abstract
out specific message types. MEPs identify placeholders for
messages, and placeholders are associated with specific message
types when an operation is defined, which includes specifying which
MEP to use for that operation. Secondly, unless explicitly stated
otherwise, MEPs also abstract out binding-specific information like
timing between messages, whether the pattern is synchronous or
asynchronous, and whether the messages are sent over a single or
multiple channels.</p>
<p>It's worth pointing out that WSDL 2.0 MEPs do not exhaustively
describe the set of messages that may be exchanged between a
service and other nodes. By some prior agreement, another node
and/or the service may send other messages (to each other or to
other nodes) that are not described by the MEP. For instance, even
though an MEP may define a single message sent from a service to
one other node, a service defined by that MEP may multicast that
message to other nodes. To maximize reuse, WSDL 2.0 message
exchange patterns identify a minimal contract between other parties
and Web Services, and contain only information that is relevant to
both the Web service and the client that engages that service.</p>
<p>A total of eight MEPs are defined in [<cite><a href=
"#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]. These MEPs should
cover the most common use cases, but they are not meant to be an
exhaustive list of MEPs that can ever be used by operations. More
MEPs can be defined for particular application needs by interested
parties. (See <a href="#more-interfaces-meps"><strong>2.4.4.3
Understanding Message Exchange Patterns (MEPs)</strong></a> )</p>
<p>For the eight MEPs defined by WSDL 2.0, some of them are
variations of others based on how faults may be generated. For
example, the In-Only pattern ("http://www.w3.org/ns/wsdl/in-only")
consists of exactly one message received by a service from some
other node. No fault can be generated. As a variation of In-Only,
Robust In-Only pattern ("http://www.w3.org/ns/wsdl/robust-in-only")
also consists of exactly one message received by a service, but in
this case faults can be triggered by the message and must be
delivered to the originator of the message. If there is no path to
this node, the fault must be discarded. For details about the
common fault generation models used by the eight WSDL 2.0 MEPs, see
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>].</p>
<p>Depending on how the first message in the MEP is initiated, the
eight WSDL 2.0 MEPs may be grouped into two groups: in-bound MEPs,
for which the service receives the first message in the exchange,
and out-bound MEPs, for which the service sends out the first
message in the exchange. (Such grouping is not provided in the WSDL
2.0 specification and is presented here only for the purpose of
easy reference in this primer).</p>
<p>A frequently asked question about out-bound MEPs is how a
service knows where to send the message. Services using out-bound
MEPs are typically part of large scale integration systems that
rely on mapping and routing facilities. In such systems, out-bound
MEPs are useful for specifying the functionality of a service
abstractly, including its requirements for potential customers,
while endpoint address information can be provided at deployment or
runtime by the underlying integration infrastructure. For example,
the GreatH hotel reservation system may require that every time a
customer interacts with the system to check availability, data
about the customer must be logged by a CRM system. At design time,
it's unknown which particular CRM system would be used together
with the reservation system. To address this requirement, we may
change the "reservationInterface" in <a href=
"#example-initial">Example 2-1</a> to include an out-bound
logInquiry operation. This <code>logInquiry</code> operation
advertises to potential service clients that customer data will be
made available by the reservation service at run time. When the
reservation service is deployed to GreatH's IT landscape,
appropriate configuration time and run time infrastructure will
help determine which CRM system will get the customer data and log
it appropriately. It's worth noting that in addition to being used
by a CRM system for customer management purpose, the same data may
also be used by a system performance analysis tool for different
purpose. Providing an out-bound operation in the reservation
service enables loose coupling and so improves the overall GreatH
IT landscape's flexibility and scalability.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-outbound-operation" id=
"example-outbound-operation"></a><em><span>Example 2-12.</span> Use
of outbound MEPs</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
                                        
&lt;description ...&gt;
        ...
        &lt;interface  name="reservationInterface"&gt;
                ...
                &lt;operation name="opCheckAvailability" ... &gt;
                
                &lt;operation name="opLogInquiry" 
                                <strong>pattern="http://www.w3.org/ns/wsdl/out-only"</strong>&gt;
                        &lt;<strong>output messageLabel="Out" element="ghns:customerData"</strong> /&gt;
                &lt;/operation&gt;

        &lt;/interface&gt;
        ...
&lt;/description&gt;
</pre></div>
</div>
<p>Although the eight MEPs defined in WSDL 2.0 Part 2
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] are
intended to cover most use cases, WSDL 2.0 has designed this set to
be extensible. This is why MEPs are identified by URIs rather than
a fixed set of tokens.</p>
<p>For more about defining new MEPs, see <a href=
"#adv-MEP"><strong>4.2 Defining New MEPs</strong></a>.</p>
</div>
</div>
</div>
<div class="div2">
<h3><a name="more-bindings" id="more-bindings"></a>2.5 More on
Bindings</h3>
<p>Bindings are used to supply protocol and encoding details that
specify <em>how</em> messages are to be sent or received. Each
<code>binding</code> element uses a particular <em>binding
extension</em> to specify such information. WSDL 2.0 Part 2
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] defines
several binding extensions that are typically used. However,
binding extensions that are not defined in WSDL 2.0 Part 2 can also
be used, provided that client and service toolkits support
them.</p>
<p>Binding information must be supplied for every operation in the
interface that is used in an endpoint. However, if the desired
binding extension provides suitable defaulting rules, then the
information will only need to be explicitly supplied at the
interface level, and the defaulting rules will implicitly propagate
the information to the operations of the interface. For example,
see the <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626#soap-defaults">
Default Binding Rules</a> of SOAP binding extension in WSDL 2.0
Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0
Adjuncts</a></cite>].</p>
<div class="div3">
<h4><a name="more-bindings-wsdl" id="more-bindings-wsdl"></a>2.5.1
Syntax Summary for Bindings</h4>
<p>Since bindings are specified using extensions to the WSDL 2.0
language (i.e., binding extensions are not in the WSDL 2.0
namespace), the XML for expressing a binding will consist of a
mixture of elements and attributes from WSDL 2.0 namespace and from
the binding extension's namespace, using WSDL 2.0's open content
model.</p>
<p>Here is a syntax summary for <code>binding</code>, simplified by
omitting optional <code>documentation</code> elements. Bear in mind
that this syntax summary only shows the elements and attributes
defined within the WSDL 2.0 namespace. When an actual binding is
defined, elements and attributes from the namespace of the desired
binding extension will also be intermingled as required by that
particular binding extension.</p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;description targetNamespace="<em>xs:anyURI</em>" &gt;
  . . .
  &lt;<strong>binding</strong> name="<em>xs:NCName</em>" interface="<em>xs:QName</em>"? &gt;

    &lt;fault ref="<em>xs:QName</em>" &gt;  &lt;/fault&gt;*

    &lt;operation ref="<em>xs:QName</em>" &gt;
      &lt;input messageLabel="<em>xs:NCName</em>"? &gt; &lt;/input&gt;*
      &lt;output messageLabel="<em>xs:NCName</em>"? &gt; &lt;/output&gt;*
      &lt;infault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? &gt; &lt;/infault&gt;*
      &lt;outfault ref="<em>xs:QName</em>" messageLabel="<em>xs:NCName</em>"? &gt; &lt;/outfault&gt;*
    &lt;/operation&gt;*

  &lt;/<strong>binding</strong>&gt;*
  . . .
&lt;/description&gt;
</pre></div>
<p>The <code>binding</code> syntax parallels the syntax of
<code>interface</code>: each interface construct has a binding
counterpart. Despite this syntactic similarity, they are indeed
different constructs, since they are in different symbol spaces and
are designed for different purposes.</p>
</div>
<div class="div3">
<h4><a name="more-bindings-reusable" id=
"more-bindings-reusable"></a>2.5.2 Reusable Bindings</h4>
<p>A binding can either be reusable (applicable to any interface)
or non-reusable (specified for a particular interface).
Non-reusable bindings may be specified at the granularity of the
interface (assuming the binding extension provides suitable
defaulting rules), or on a per-operation basis if needed. A
non-reusable binding was demonstrated in <a href=
"#basics-binding"><strong>2.1.5 Defining a
Binding</strong></a>.</p>
<p>To define a reusable binding, the <code>binding</code> element
simply omits the <code>interface</code> attribute and omits
specifying any operation-specific and fault-specific binding
details. Endpoints can later refer to a reusable binding in the
same manner as for a non-reusable binding. Thus, a reusable binding
becomes associated with a particular interface when it is
referenced from an endpoint, because an endpoint is part of a
service, and the service specifies a particular interface that it
implements. Since a reusable binding does not specify an interface,
reusable bindings cannot specify operation-specific details.
Therefore, reusable bindings can only be defined using binding
extensions that have suitable defaulting rules, such that the
binding information only needs to be explicitly supplied at the
interface level.</p>
</div>
<div class="div3">
<h4><a name="more-bindings-faults" id=
"more-bindings-faults"></a>2.5.3 Binding Faults</h4>
<p>A binding <code>fault</code> associates a concrete message
format with an abstract fault of an interface. It describes how
faults that occur within a message exchange of an operation will be
formatted, since the fault does not occur by itself. Rather, a
fault occurs as part of a message exchange specified by an
interface <code>operation</code> and its binding counterpart, the
binding <code>operation</code>.</p>
<p>A binding <code>fault</code> has one required <code>ref</code>
attribute which is a reference, by QName, to an
<code>interface</code> <code>fault</code>. It identifies the
abstract interface <code>fault</code> for which binding information
is being specified. Be aware that the value of <code>ref</code>
attribute of all the <code>faults</code> under a
<code>binding</code> must be unique. That is, one cannot define
multiple bindings for the same interface fault within a given
<code>binding</code>.</p>
</div>
<div class="div3">
<h4><a name="bindingOperations" id="bindingOperations"></a>2.5.4
Binding Operations</h4>
<p>A binding <code>operation</code> describes a concrete binding of
an interface operation to a concrete message format. An interface
operation is uniquely identified by the WSDL 2.0 target namespace
of the interface and the name of the operation within that
interface, via the required <code>ref</code> attribute of binding
<code>operation</code>. As with faults, for each
<code>operation</code> within a <code>binding</code>, the value of
the <code>ref</code> attribute must be unique.</p>
</div>
<div class="div3">
<h4><a name="more-bindings-soap" id="more-bindings-soap"></a>2.5.5
The SOAP Binding Extension</h4>
<p>The WSDL 2.0 SOAP Binding Extension (see WSDL 2.0 Part 2
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>]) was
primarily designed to support the features of SOAP 1.2
[<cite><a href="#SOAP12-PART1">SOAP 1.2 Part 1: Messaging
Framework</a></cite>]. However, for backwards compatibility, it
also provides some support for SOAP 1.1 [<cite><a href=
"#SOAP11">SOAP 1.1</a></cite>].</p>
<p>An example using the WSDL 2.0 SOAP binding extension was already
presented in <a href="#basics-binding"><strong>2.1.5 Defining a
Binding</strong></a>, but some additional points are worth
mentioning:</p>
<ul>
<li>
<p>Because the same binding extension is used for both SOAP 1.2 and
SOAP 1.1, a <code>wsoap:version</code> attribute is provided to
allow you to indicate which version of SOAP you want. If this
attribute is not specified, it defaults to SOAP 1.2.</p>
</li>
<li>
<p>The WSDL 2.0 SOAP binding extension defines a set of default
rules, so that bindings can be specified at the interface level or
at the operation level (or both), with the operation level taking
precedence. However, it does not define default binding rules for
faults. Thus, if a given interface defines any faults, then
corresponding binding information must be explicitly provided for
each such fault.</p>
</li>
<li>
<p>If HTTP is used as the underlying protocol, then the binding can
(and should) control whether each operation will use HTTP GET or
POST. (See <a href="#adv-get-vs-post"><strong>2.5.7 HTTP GET Versus
POST: Which to Use?</strong></a>.)</p>
</li>
</ul>
<p>Here is an example that illustrates both a SOAP 1.2 binding (as
seen before) and a SOAP 1.1 binding.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-binding-soap" id=
"example-binding-soap"></a><em><span>Example 2-13.</span> SOAP 1.2
and SOAP 1.1 Bindings</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description 
  xmlns="http://www.w3.org/ns/wsdl"
  targetNamespace="http://greath.example.com/2004/wsdl/resSvc" 
  xmlns:tns="http://greath.example.com/2004/wsdl/resSvc"
  xmlns:ghns="http://greath.example.com/2004/schemas/resSvc"
  xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
  xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
  xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"&gt;

 ....

  &lt;!-- SOAP 1.2 Binding --&gt;
  &lt;binding name="reservationSOAPBinding" 
    interface="tns:reservationInterface"
    type="http://www.w3.org/ns/wsdl/soap"
    wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"&gt;

    &lt;operation ref="tns:opCheckAvailability" 
      wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response"/&gt;
  
    &lt;fault ref="tns:invalidDataFault" 
      wsoap:code="soap:Sender"/&gt;

  &lt;/binding&gt;
  
  &lt;!-- SOAP 1.1 Binding --&gt;
  &lt;binding name="reservationSOAP11Binding" 
    interface="tns:reservationInterface"
    type="http://www.w3.org/ns/wsdl/soap"
    wsoap:version="1.1"
    wsoap:protocol="http://www.w3.org/2006/01/soap11/bindings/HTTP/"&gt;
  
    &lt;operation ref="tns:opCheckAvailability"/&gt;
  
    &lt;fault ref="tns:invalidDataFault" 
      wsoap:code="soap11:Client"/&gt;

  &lt;/binding&gt;


  &lt;service name="reservationService" 
    interface="tns:reservationInterface"&gt;

    &lt;!-- SOAP 1.2 End Point --&gt;
    &lt;endpoint name="reservationEndpoint" 
      binding="tns:reservationSOAPBinding"
      address="http://greath.example.com/2004/reservation"/&gt;

    &lt;!-- SOAP 1.1 End Point --&gt;
    &lt;endpoint name="reservationEndpoint2"
      binding="tns:reservationSOAP11Binding"
      address="http://greath.example.com/2004/reservation"/&gt;
  
  &lt;/service&gt;  
&lt;/description&gt;

</pre></div>
</div>
<div class="div4">
<h5><a name="more-bindings-soap-example-explanation" id=
"more-bindings-soap-example-explanation"></a>2.5.5.1 Explanation of
Example</h5>
<p>Most lines in this example is the same as previously explained
in <a href="#basics-binding"><strong>2.1.5 Defining a
Binding</strong></a>, so we'll only point out lines that are
demonstrating something new for SOAP 1.1 binding.</p>
<dl>
<dt class="label"><code>&lt;description ...
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"&gt;</code></dt>
<dd>
<p>This is the namespace for terms defined within the SOAP 1.1
specification [<cite><a href="#SOAP11">SOAP 1.1</a></cite>].</p>
</dd>
<dt class="label">
<code>&lt;binding...wsoap:version="1.1"</code></dt>
<dd>
<p>This line indicates that this binding uses SOAP 1.1
[<cite><a href="#WSDL-SOAP11">WSDL 2.0 SOAP 1.1
Binding</a></cite>], rather than SOAP 1.2.</p>
</dd>
<dt class="label">
<code>wsoap:protocol="http://www.w3.org/2006/01/soap11/bindings/HTTP/"&gt;</code></dt>
<dd>
<p>This line specifies that HTTP should be used as the underlying
transmission protocol. See also <a href=
"#adv-get-vs-post"><strong>2.5.7 HTTP GET Versus POST: Which to
Use?</strong></a>.</p>
</dd>
<dt class="label"><code>&lt;operation
ref="tns:opCheckAvailability"/&gt;</code></dt>
<dd>
<p>Note that <code>wsoap:mep</code> is not applicable to SOAP 1.1
binding.</p>
</dd>
<dt class="label">
<code>&lt;fault...wsoap:code="soap11:Client"/&gt;</code></dt>
<dd>
<p>This line specifies the SOAP 1.1 fault code that will be used in
transmitting invalidDataFault.</p>
</dd>
</dl>
</div>
</div>
<div class="div3">
<h4><a name="more-bindings-http" id="more-bindings-http"></a>2.5.6
The HTTP Binding Extension</h4>
<p>In addition to the WSDL 2.0 SOAP binding extension described
above, WSDL 2.0 Part 2 [<cite><a href="#WSDL-PART2">WSDL 2.0
Adjuncts</a></cite>] defines a binding extension for HTTP 1.1
[<cite><a href="#RFC2616">IETF RFC 2616</a></cite>] and HTTPS
[<cite><a href="#RFC2818">IETF RFC 2818</a></cite>], so that these
protocols can be used natively to send and receive messages,
without first encoding them in SOAP.</p>
<p>The HTTP binding extension provides many features to
control:</p>
<ul>
<li>
<p>Which HTTP operation will be used. (GET, PUT, POST, DELETE, and
other HTTP operations are supported.)</p>
</li>
<li>
<p>Input, output and fault serialization</p>
</li>
<li>
<p>Transfer codings</p>
</li>
<li>
<p>Authentication requirements</p>
</li>
<li>
<p>Cookies</p>
</li>
<li>
<p>HTTP over TLS (https)</p>
</li>
</ul>
<p>As with the WSDL 2.0 SOAP binding extension, the HTTP binding
extension also provides defaulting rules to permit binding
information to be specified at the interface level and used by
default for each operation in the affected interface, however,
defaulting rules are not provided for binding faults.</p>
<p>Here is an example of using the HTTP binding extension to check
hotel room availability at GreatH.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-bindings-http" id=
"example-bindings-http"></a><em><span>Example 2-14.</span> HTTP
Binding Extension</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt; 
&lt;description xmlns="http://www.w3.org/ns/wsdl"
      . . .
      xmlns:whttp="http://www.w3.org/ns/wsdl/http" &gt;

  . . .
  &lt;binding name="reservationHTTPBinding"
      interface="tns:reservationInterface"
      type="http://www.w3.org/ns/wsdl/http"
      whttp:methodDefault="GET"&gt;

    &lt;operation ref="tns:opCheckAvailability"
      whttp:location="{checkInDate}"  /&gt;
  &lt;/binding&gt;

  &lt;service name="reservationService"
    interface="tns:reservationInterface"&gt;

    &lt;!-- HTTP 1.1 GET End Point --&gt;
    &lt;endpoint name="reservationEndpoint"
      binding="tns:reservationHTTPBinding"
      address="http://greath.example.com/2004/checkAvailability/"/&gt;

  &lt;/service&gt;
  . . .
&lt;/description&gt;
</pre></div>
</div>
<div class="div4">
<h5><a name="id2297429" id="id2297429"></a>2.5.6.1 Explanation of
Example</h5>
<p>Most of this example is the same as previously explained in
<a href="#basics-binding"><strong>2.1.5 Defining a
Binding</strong></a>, so we'll only point out lines that are
demonstrating something new for HTTP binding extension.</p>
<dl>
<dt class="label">
<code>&lt;description...xmlns:whttp="http://www.w3.org/ns/wsdl/http"
&gt;</code></dt>
<dd>
<p>This defines the namespace prefix for elements and attributes
defined by the WSDL 2.0 HTTP binding extension.</p>
</dd>
<dt class="label">
<code>&lt;binding...type="http://www.w3.org/ns/wsdl/http"</code></dt>
<dd>
<p>This declares the binding as being an HTTP binding.</p>
</dd>
<dt class="label"><code>whttp:methodDefault="GET"&gt;</code></dt>
<dd>
<p>The default method for operations in this interface will be HTTP
GET.</p>
</dd>
<dt class="label"><code>whttp:location="{checkInDate}"
&gt;</code></dt>
<dd>
<p>The <code>whttp:location</code> attribute specifies a pattern
for serializing input message instance data into the path component
of the request URI. The default binding rules for HTTP specify that
the default input serialization for GET is
<code>application/x-www-form-urlencoded</code>. Curly braces are
used to specify the name of a schema type in the input message
schema, which determines what input instance data will be inserted
into the path component of the request URI. The curly
brace-enclosed name will be replaced with instance data in
constructing the path component. Remaining input instance data (not
specified by <code>whttp:location</code>) will either be serialized
into the query string portion of the URI or into the message body,
as follows: if a "/" is appended to a curly brace-enclosed type
name, then any remaining input message instance data will be
serialized into the message body. Otherwise it will be serialized
into query parameters.</p>
<p>Thus, in this example, each of the elements in the
<code>tCheckAvailability</code> type will be serialized into the
query parameters. A sample resulting URI would therefore be
<code>http://greath.example.com/2004/checkAvailability/5-5-5?checkOutDate=6-6-5&amp;roomType=foo</code>.</p>
</dd>
</dl>
<p>Here is an alternate example that appends "/" to the type name
in order to serialize the remaining instance data into the message
body:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-bindings-http-path-subsset" id=
"example-bindings-http-path-subsset"></a><em><span>Example
2-15.</span> Serializing a Subset of Types in the Path</em></p>
<div class="exampleInner">
<pre xml:space="preserve">

. . .
&lt;operation ref="tns:opCheckAvailability"
    whttp:location="bycheckInDate/{checkInDate/}"  &gt;
. . .
</pre></div>
</div>
<p>This would instead serialize to a request URI such as:
<code>http://greath.example.com/2004/checkAvailability/bycheckInDate/5-5-5</code>.
The rest of the message content would go to the HTTP message
body.</p>
</div>
</div>
<div class="div3">
<h4><a name="adv-get-vs-post" id="adv-get-vs-post"></a>2.5.7 HTTP
GET Versus POST: Which to Use?</h4>
<p>When a binding using HTTP is specified for an operation, the
WSDL 2.0 author must decide which HTTP method is appropriate to use
-- usually a choice between GET and POST. In the context of the Web
as a whole (rather than specifically Web services), the W3C
Technical Architecture Group (TAG) has addressed the question of
when it is appropriate to use GET, versus when to use POST, in a
finding entitled <em>URIs, Addressability, and the use of HTTP GET
and POST</em> ([<cite><a href="#TAG-whenToUseGET">W3C TAG Finding:
Use of HTTP GET</a></cite>]). From the abstract:</p>
<p>"<em>. . . designers should adopt [GET] for safe operations such
as simple queries. POST is appropriate for other types of
applications where a user request has the potential to change the
state of the resource (or of related resources). The finding
explains how to choose between HTTP GET and POST for an application
taking into account architectural, security, and practical
considerations.</em>"</p>
<p>Recall that the concept of a safe operation was discussed in
<a href="#more-interfaces-op-attr"><strong>2.4.4.1 Operation
Attributes</strong></a>. (Briefly, a safe operation is one that
does not cause the invoker to incur new obligations.) Although the
<code>wsdlx:safe</code> attribute of an interface operation
indicates that the abstract operation is safe, it does not
automatically cause GET to be used at the HTTP level when the
binding is specified. The choice of GET or POST is determined at
the binding level:</p>
<ul>
<li>
<p>If the WSDL 2.0 SOAP binding extension is used (<a href=
"#more-bindings-soap"><strong>2.5.5 The SOAP Binding
Extension</strong></a>), with HTTP as the underlying transport
protocol, then GET may be specified by setting:</p>
<dl>
<dt class="label">
<code>wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"</code></dt>
<dd>
<p>on the <code>binding</code> element (to indicate the use of HTTP
as the underlying protocol); and</p>
</dd>
<dt class="label">
<code>wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response/"</code></dt>
<dd>
<p>on the binding <code>operation</code> element, which causes GET
to be used by default.</p>
</dd>
</dl>
</li>
<li>
<p>If the WSDL 2.0 HTTP binding extension is used directly
(<a href="#more-bindings-http"><strong>2.5.6 The HTTP Binding
Extension</strong></a>), GET may be specified by setting
either:</p>
<dl>
<dt class="label"><code>whttp:methodDefault="GET"</code></dt>
<dd>
<p>on the <code>binding</code> element; or</p>
</dd>
<dt class="label"><code>whttp:method="GET"</code></dt>
<dd>
<p>on the binding <code>operation</code> element, which overrides
<code>whttp:methodDefault</code> if set on the <code>binding</code>
element; or</p>
</dd>
<dt class="label"><code>wsdlx:safe="true"</code></dt>
<dd>
<p>on the bound <code>interface operation</code> . When the above
two items are not explicitly set, and when the bound interface
operation is marked safe, the HTTP Binding will by default set the
method to GET.</p>
</dd>
</dl>
</li>
</ul>
<p>For example, in the GreatH interface definition shown in
<a href="#example-initial-interface">Example 2-4</a>, the
wsdlx:safe attribute is set to "true". The HTTP binding definition
in <a href="#example-bindings-http">Example 2-14</a> may take
advantage of that and be simplified as below and still have the
http method set to GET by default:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-binding-safety" id=
"example-binding-safety"></a><em><span>Example 2-16.</span> Safety
and HTTP Binding</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt;  

&lt;binding name="reservationHTTPBinding"

      interface="tns:reservationInterface"

      type="http://www.w3.org/ns/wsdl/http" &gt;

    &lt;operation ref="tns:opCheckAvailability"

        whttp:location="{checkInDate}"/&gt;

  &lt;/binding&gt;
</pre></div>
</div>
</div>
</div>
</div>
<div class="div1">
<h2><a name="advanced-topic_ii" id="advanced-topic_ii"></a>3.
Advanced Topics I: Importing Mechanisms</h2>
<div class="div2">
<h3><a name="adv-import-and-authoring" id=
"adv-import-and-authoring"></a>3.1 Importing WSDL</h3>
<p>In some circumstances WSDL authors may want to split up a Web
service description into two or more documents. For example, if a
description is getting long or is being developed by several
authors, then it is convenient to divide it into several parts.
Another very important case is when you expect parts of the
description to be reused in several contexts. Clearly it is
undesirable to cut and paste sections of one document into another,
since that is error prone and leads to maintenance problems. More
importantly, you may need to reuse components that belong to a
wsdl:targetNamespace that is different than that of the document
you are writing, in which case the rules of WSDL 2.0 prevent you
from simply cutting and pasting them into your document.</p>
<p>To solve these problems, WSDL 2.0 provides two mechanisms for
modularizing Web service description documents: <code>import</code>
and <code>include</code>. This section discusses the import
mechanism and describes some typical cases where it may be
used.</p>
<p>The <code>import</code> mechanism lets one refer to the
definitions of Web service components that belong to other
namespaces. To illustrate this, consider the GreatH hotel
reservation service. Suppose that the reservation service uses a
standard credit card validation service that is provided by a
financial services company. Furthermore, suppose that companies in
the financial services industry decided that it would be useful to
report errors in credit card validation using a common set of
faults, and have defined these faults in the following Web service
description:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"credit-card-faults" id="credit-card-faults"></a><em><span>Example
3-1.</span> Standard Credit Card Validation Faults
(credit-card-faults.wsdl)</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;description xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://finance.example.com/CreditCards/wsdl"
        xmlns:tns="http://finance.example.com/CreditCards/wsdl"
        xmlns:cc="http://finance.example.com/CreditCards/xsd"&gt;

  &lt;documentation&gt;
        This document describes standard faults for use 
      by Web services that process credit cards.
  &lt;/documentation&gt;

  &lt;types&gt;
        &lt;xs:import xmlns:xs="http://www.w3.org/2001/XMLSchema"
            namespace="http://finance.example.com/CreditCardFaults/xsd"
            schemaLocation="credit-card-faults.xsd" /&gt;
  &lt;/types&gt;

  &lt;interface name="creditCardFaults"&gt;

        &lt;fault name="cancelledCreditCard" element="cc:CancelledCreditCard"&gt;
            &lt;documentation&gt;Thrown when the credit card has been cancelled.&lt;/documentation&gt;
        &lt;/fault&gt;
                
        &lt;fault name="expiredCreditCard" element="cc:ExpiredCreditCard"&gt;
            &lt;documentation&gt;Thrown when the credit card has expired.&lt;/documentation&gt;
        &lt;/fault&gt;
                
        &lt;fault name="invalidCreditCardNumber" element="cc:InvalidCreditCardNumber"&gt;
            &lt;documentation&gt;Thrown when the credit card number is invalid.
                This fault will occur if the wrong credit card type is specified.
          &lt;/documentation&gt;
        &lt;/fault&gt;
                
        &lt;fault name="invalidExpirationDate" element="cc:InvalidExpirationDate"&gt;
            &lt;documentation&gt;Thrown when the expiration date is invalid.&lt;/documentation&gt;
        &lt;/fault&gt;

  &lt;/interface&gt;

&lt;/description&gt;
</pre></div>
</div>
<p>This example defines an interface,
<code>creditCardFaults</code>, that contains four faults,
<code>cancelledCreditCard</code>, <code>expiredCreditCard</code>,
<code>invalidCreditCardNumber</code>, and
<code>invalidExpirationDate</code>. These components belong to the
namespace
<code>http://finance.example.com/CreditCards/wsdl</code>.</p>
<p>Because these faults are defined in a different
wsdl:targetNamespace than the one used by the GreatH Web service
description, import must be used to make them available within the
GreatH Web service description, as shown in the following
example:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"use-credit-card-faults" id=
"use-credit-card-faults"></a><em><span>Example 3-2.</span> Using
the Standard Credit Card Validation Faults
(use-credit-card-faults.wsdl)</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0"?&gt;
&lt;description
        targetNamespace="http://greath.example.com/2004/wsdl/resSvc"
        xmlns:ghns="http://greath.example.com/2004/schemas/resSvc"
        xmlns:cc="http://finance.example.com/CreditCards/wsdl"
        xmlns="http://www.w3.org/ns/wsdl"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

        &lt;documentation&gt;
                Description: The definition of the reservation Web service of
                GreatH hotel. Author: Joe Somebody Date: 05/17/2004
        &lt;/documentation&gt;
        
        &lt;import namespace="http://finance.example.com/CreditCards/wsdl" 
              location="credit-card-faults.wsdl"/&gt;
        . . .
        &lt;interface name="reservation" extends="cc:creditCardFaults"&gt;
                . . . 
                &lt;operation name="makeReservation"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;

                        &lt;input messageLabel="In" element="ghns:makeReservation" /&gt;

                        &lt;output messageLabel="Out"
                                element="ghns:makeReservationResponse" /&gt;

                        &lt;outfault ref="invalidDataFault" messageLabel="Out" /&gt;

                        &lt;outfault ref="cc:cancelledCreditCard" messageLabel="Out" /&gt;
                        &lt;outfault ref="cc:expiredCreditCard" messageLabel="Out" /&gt;
                        &lt;outfault ref="cc:invalidCreditCardNumber" messageLabel="Out" /&gt;
                        &lt;outfault ref="cc:invalidExpirationDate" messageLabel="Out" /&gt;
                &lt;/operation&gt;
        &lt;/interface&gt;
&lt;/description&gt;
</pre></div>
</div>
<p>The hotel reservation service declares that it is using
components from another namespace via the <code>import</code>&gt;
element. The import element has a required <code>namespace</code>
attribute that specifies the other namespace, and an optional
<code>location</code> attribute that gives the processor a hint
where to find the description of the other namespace. The
<code>reservation</code> interface extends the
<code>creditCardFault</code> interface from the other namespace in
order to make the faults available in the reservation interface.
Finally, the <code>makeReservation</code> operation refers to the
standard faults in its <code>outfault</code> elements.</p>
<p>Another typical situation for using imports is to define a
standard interface that is to be implemented by many services. For
example, suppose the hotel industry decided that it was useful to
have a standard interface for making reservations. This interface
would belong to some industry association namespace, e.g.
<code>http://hotels.example.com/reservations/wsdl</code>. Each
hotel that implemented the standard reservation service would
define a service in its own namespace, e.g.
<code>http://greath.example.com/2004/wsdl/resSvc</code>. The
description of each service would import the
<code>http://hotels.example.com/reservations/wsdl</code> namespace
and refer to the standard reservation interface in it.</p>
</div>
<div class="div2">
<h3><a name="adv-multiple-inline-schemas" id=
"adv-multiple-inline-schemas"></a>3.2 Importing Schemas</h3>
<p>WSDL 2.0 documents may contain one or more XML schemas defined
within the <code>wsdl:types</code> element. This section
illustrates the correct way to refer to these schemas, both from
within the same document and from other documents.</p>
<div class="div3">
<h4><a name="id2298427" id="id2298427"></a>3.2.1 Schemas in
Imported Documents</h4>
<p>In this example, we consider some GreatH Hotel Web services that
retrieve and update reservation details. The retrieval Web service
is defined in the <code>retrieveDetails.wsdl</code> WSDL 2.0
document, along with a schema for the message format. The updating
Web service is defined in the <code>updateDetails.wsdl</code> WSDL
2.0 document which imports the first document and refers to both
WSDL 2.0 and schema definitions contained in the imported
document.</p>
<p><a href="#retrieveDetails.wsdl">Example 3-3</a> shows the
definition of the retrieval Web service in the
<code>http://greath.example.com/2004/services/retrieveDetails</code>
namespace. This WSDL 2.0 document also contains an inline schema
that describes the reservation detail in the
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
namespace. This schema is visible to the
<code>retrieveDetailsInterface</code> interface definition which
refers to it in the <code>retrieve</code> operation's output
message.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"retrieveDetails.wsdl" id=
"retrieveDetails.wsdl"></a><em><span>Example 3-3.</span> The
Retrieve Reservation Details Web Service:
retrieveDetails.wsdl</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
                                                        &lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;description xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:tns="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

        &lt;documentation&gt;
                This document describes the GreatH Retrieve Reservation Details
                Web service.
        &lt;/documentation&gt;

        &lt;types&gt;
                &lt;xs:schema xmlns="http://www.w3.org/2001/XMLSchema"
                        targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"&gt;

                        &lt;xs:element name="reservationDetails"&gt;
                                &lt;xs:complexType&gt;
                                        &lt;xs:sequence&gt;
                                                &lt;xs:element name="confirmationNumber"
                                                        type="string" /&gt;
                                                &lt;xs:element name="checkInDate" type="date" /&gt;
                                                &lt;xs:element name="checkOutDate" type="date" /&gt;
                                                &lt;xs:element name="roomType" type="string" /&gt;
                                                &lt;xs:element name="smoking" type="boolean" /&gt;
                                        &lt;/xs:sequence&gt;
                                &lt;/xs:complexType&gt;
                        &lt;/xs:element&gt;
                &lt;/xs:schema&gt;
        &lt;/types&gt;

        &lt;interface name="retrieveDetailsInterface"&gt;

                &lt;operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In" element="#none" /&gt;
                        &lt;output messageLabel="Out"
                                element="wdetails:reservationDetails" /&gt;
                &lt;/operation&gt;

        &lt;/interface&gt;

&lt;/description&gt;
                                                
</pre></div>
</div>
<p><a href="#updateDetails.wsdl">Example 3-4</a> shows the
definition of the updating Web service in the
<code>http://greath.example.com/2004/services/updateDetails</code>
namespace. The <code>updateDetailsInterface</code> interface
extends the <code>retrieveDetailsInterface</code> interface.
However, the <code>retrieveDetailsInterface</code> belongs to the
<code>http://greath.example.com/2004/services/retrieveDetails</code>
namespace, so <code>updateDetails.wsdl</code> must import
<code>retrieveDetails.wsdl</code> to make that namespace
visible.</p>
<p>The <code>updateDetailsInterface</code> interface also uses the
<code>reservationDetails</code> element definition that is
contained in the inline schema of the imported
<code>retrieveDetails.wsdl</code> document. However, this schema is
not automatically visible within the
<code>updateDetails.wsdl</code> document. To make it visible, the
<code>updateDetails.wsdl</code> document must import the namespace
of the inline schema within the <code>types</code> element using
the XML schema <code>import</code> element.</p>
<p>In this example, the <code>schemaLocation</code> attribute of
the <code>import</code> element has been omitted. The
<code>schemaLocation</code> attribute is a hint to the WSDL 2.0
processor that tells it where to look for the imported schema
namespace. However, the WSDL 2.0 processor has already processed
the <code>retrieveDetails.wsdl</code> document which contains the
imported namespace in an inline schema so it should not need any
hints. However, this behavior depends on the implementation of the
processor and so cannot be relied on.</p>
<p>Although the WSDL 2.0 document may validly omit the
<code>schemaLocation</code> attribute, it is a best practice to
either provide a reliable value for it or move the inline schema
into a separate document, say <code>reservationDetails.xsd</code>,
and directly import it in the <code>types</code> element of both
<code>retrieveDetails.wsdl</code> and
<code>updateDetails.wsdl</code>. In general, schemas that are
expected to be referenced from more than one WSDL 2.0 document
should be defined in a separate schema document rather than be
inlined.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"updateDetails.wsdl" id="updateDetails.wsdl"></a><em><span>Example
3-4.</span> The Update Reservation Details Web Service:
updateDetails.wsdl</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;description xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/updateDetails"
        xmlns:tns="http://greath.example.com/2004/services/updateetails"
        xmlns:retrieve="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

        &lt;documentation&gt;
                This document describes the GreatH Update Reservation Details
                Web service.
        &lt;/documentation&gt;

        &lt;import
                namespace="http://greath.example.com/2004/services/retrieveDetails"
                location="retrieveDetails.wsdl" /&gt;

        &lt;types&gt;
                &lt;xs:import
                        namespace="http://greath.example.com/2004/schemas/reservationDetails" /&gt;
        &lt;/types&gt;

        &lt;interface name="updateDetailsInterface"
                extends="retrieve:retrieveDetailsInterface"&gt;

                &lt;operation name="update"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In"
                                element="details:reservationDetails" /&gt;
                        &lt;output messageLabel="Out"
                                element="details:reservationDetails" /&gt;
                &lt;/operation&gt;

        &lt;/interface&gt;

&lt;/description&gt;
</pre></div>
</div>
</div>
<div class="div3">
<h4><a name="id2298802" id="id2298802"></a>3.2.2 Multiple Inline
Schemas in One Document</h4>
<p>A WSDL 2.0 document may define multiple inline schemas in its
<code>types</code> element. The two or more schemas may have the
same target namespace provided that they do not define the same
elements or types. It is an error to define the same element or
type more than once, even if the definitions are identical.</p>
<p>Each namespace of an inline schema becomes visible to the Web
service definitions. However, the namespaces are not automatically
visible to the other inline schemas. Each inline schema must
explicitly import any other namespace it references. The
<code>schemaLocation</code> attribute is not required in this case
since the WSDL 2.0 processor knows the location of each schema by
virtue of having processed the enclosing WSDL 2.0 document.</p>
<p>To illustrate this, consider <a href=
"#retrieveItems.wsdl">Example 3-5</a> which contains two inline
schemas. The
<code>http://greath.example.com/2004/schemas/reservationItems</code>
namespace contains some elements for items that appear in the
reservation details. The
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
namespace contains the <code>reservationDetails</code> element
which refers to the item elements. The schema for the
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
namespace contains an <code>import</code> element that imports the
<code>http://greath.example.com/2004/schemas/reservationItems</code>
namespace. No <code>schemaLocation</code> attribute is required for
this import since the schema is defined inline in the importing
document.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"retrieveItems.wsdl" id="retrieveItems.wsdl"></a><em><span>Example
3-5.</span> Multiple Inline Schemas: retrieveItems.wsdl</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;description xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:tns="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

        &lt;documentation&gt;
                This document describes the GreatH Retrieve Reservation Details
                Web service.
        &lt;/documentation&gt;

        &lt;types&gt;

                &lt;xs:schema targetNamespace="http://greath.example.com/2004/schemas/reservationItems"&gt;

                        &lt;xs:element name="confirmationNumber" type="string" /&gt;
                        &lt;xs:element name="checkInDate" type="date" /&gt;
                        &lt;xs:element name="checkOutDate" type="date" /&gt;
                        &lt;xs:element name="roomType" type="string" /&gt;
                        &lt;xs:element name="smoking" type="boolean" /&gt;

                &lt;/xs:schema&gt;

                &lt;xs:schema targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"
                        xmlns:items="http://greath.example.com/2004/schemas/reservationItems"&gt;

                        &lt;xs:import
                                namespace="http://greath.example.com/2004/schemas/reservationItems" /&gt;

                        &lt;xs:element name="reservationDetails"&gt;
                                &lt;xs:complexType&gt;
                                        &lt;xs:sequence&gt;
                                                &lt;xs:element ref="items:confirmationNumber" /&gt;
                                                &lt;xs:element ref="items:checkInDate" /&gt;
                                                &lt;xs:element ref="items:checkOutDate" /&gt;
                                                &lt;xs:element ref="items:roomType" /&gt;
                                                &lt;xs:element ref="items:smoking" /&gt;
                                        &lt;/xs:sequence&gt;
                                &lt;/xs:complexType&gt;
                        &lt;/xs:element&gt;
                &lt;/xs:schema&gt;

        &lt;/types&gt;

        &lt;interface name="retrieveDetailsInterface"&gt;

                &lt;operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In" element="#none" /&gt;
                        &lt;output messageLabel="Out"
                                element="wdetails:reservationDetails" /&gt;
                &lt;/operation&gt;

        &lt;/interface&gt;

&lt;/description&gt;
</pre></div>
</div>
</div>
<div class="div3">
<h4><a name="adv-schema-location" id=
"adv-schema-location"></a>3.2.3 The schemaLocation Attribute</h4>
<p>In the preceding examples, schemas were defined inline in WSDL
2.0 documents. This section discusses the correct way to specify a
<code>schemaLocation</code> attribute on a schema
<code>import</code> element to provide a processor with a hint for
locating these schemas.</p>
<p><a href="#updateDetails.wsdl">Example 3-4</a> shows how one WSDL
2.0 document imports a schema defined in another, i.e. <a href=
"#retrieveDetails.wsdl">Example 3-3</a>. Similarly, <a href=
"#retrieveItems.wsdl">Example 3-5</a> shows how one schema in a
WSDL 2.0 document imports another schema defined in the same
document. In both of these examples, the
<code>schemaLocation</code> attribute was omitted since the WSDL
2.0 processor was assumed to know how to locate the imported
schemas because they were part of the WSDL 2.0 documents being
processed. The <code>schemaLocation</code> attribute can be used to
give the processor a URI reference that explicitly locates the
schemas. A URI reference is a URI plus an optional fragment
identifier that indicates part of the resource. For schemas, the
fragment should identify the <code>schema</code> element. The
simplest way to accomplish this is to use the <code>id</code>
attribute, however XPointer (see [<cite><a href="#XPTR">XPointer
Framework</a></cite>]) can also be used.</p>
<div class="div4">
<h5><a name="id2299144" id="id2299144"></a>3.2.3.1 Using the id
Attribute to Identify Inline Schemas</h5>
<p><a href="#schemaIds.wsdl">Example 3-6</a> shows the use of the
<code>id</code> attribute. Both of the inline schemas have
<code>id</code> attributes. The id of the
<code>http://greath.example.com/2004/schemas/reservationItems</code>
schema is <code>items</code> and the id of the
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
schema is <code>details</code>. The <code>import</code> element in
the
<code>http://greath.example.com/2004/schemas/reservationDetails</code>
schema uses the id of the
<code>http://greath.example.com/2004/schemas/reservationItems</code>
schema in the <code>schemaLocation</code> attribute, i.e.
<code>#items</code>.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"schemaIds.wsdl" id="schemaIds.wsdl"></a><em><span>Example
3-6.</span> Using Ids in Inline Schemas: schemaIds.wsdl</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;description xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:tns="http://greath.example.com/2004/services/retrieveDetails"
        xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

        &lt;documentation&gt;
                This document describes the GreatH Retrieve Reservation Details
                Web service.
        &lt;/documentation&gt;

        &lt;types&gt;

                &lt;xs:schema id="items"
                        targetNamespace="http://greath.example.com/2004/schemas/reservationItems"&gt;

                        &lt;xs:element name="confirmationNumber" type="string" /&gt;
                        &lt;xs:element name="checkInDate" type="date" /&gt;
                        &lt;xs:element name="checkOutDate" type="date" /&gt;
                        &lt;xs:element name="roomType" type="string" /&gt;
                        &lt;xs:element name="smoking" type="boolean" /&gt;

                &lt;/xs:schema&gt;

                &lt;xs:schema id="details"
                        targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"
                        xmlns:items="http://greath.example.com/2004/schemas/reservationItems"&gt;

                        &lt;xs:import
                                namespace="http://greath.example.com/2004/schemas/reservationItems"
                                schemaLocation="#items" /&gt;

                        &lt;xs:element name="reservationDetails"&gt;
                                &lt;xs:complexType&gt;
                                        &lt;xs:sequence&gt;
                                                &lt;xs:element ref="items:confirmationNumber" /&gt;
                                                &lt;xs:element ref="items:checkInDate" /&gt;
                                                &lt;xs:element ref="items:checkOutDate" /&gt;
                                                &lt;xs:element ref="items:roomType" /&gt;
                                                &lt;xs:element ref="items:smoking" /&gt;
                                        &lt;/xs:sequence&gt;
                                &lt;/xs:complexType&gt;
                        &lt;/xs:element&gt;
                &lt;/xs:schema&gt;

        &lt;/types&gt;

        &lt;interface name="retrieveDetailsInterface"&gt;

                &lt;operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In" element="#none" /&gt;
                        &lt;output messageLabel="Out"
                                element="wdetails:reservationDetails" /&gt;
                &lt;/operation&gt;

        &lt;/interface&gt;

&lt;/description&gt;
</pre></div>
</div>
</div>
</div>
</div>
</div>
<div class="div1">
<h2><a name="advanced-topic_iii" id="advanced-topic_iii"></a>4.
Advanced Topics II: Extensibility and Predefined Extensions</h2>
<div class="div2">
<h3><a name="adv-extensibility" id="adv-extensibility"></a>4.1
Extensibility</h3>
<p>WSDL 2.0 provides an open content model, which allows XML
elements and attributes from other (non-WSDL 2.0) XML namespaces to
be interspersed in a WSDL 2.0 document. The qualified name
(complete with namespace URI) of the extension element or attribute
acts as an unambiguous name for the semantics of that
extension.</p>
<p>The namespace URI of the extension element should be
dereferenceable to a document that describes the semantics of that
extension. As of this writing, there is no generally accepted
standard for what kind of document that should be. However, the
<a href="http://www.w3.org/2001/tag/">W3C TAG</a> has been
discussing the issue (see TAG issue <a href=
"http://www.w3.org/2001/tag/issues.html?type=1#namespaceDocument-8">
namespaceDocument-8</a>) and is likely to provide guidance at some
point.</p>
<div class="div3">
<h4><a name="adv-optional-versus-required" id=
"adv-optional-versus-required"></a>4.1.1 Optional Versus Required
Extensions</h4>
<p>Extensions can either be required or optional.</p>
<p>An <em>optional</em> extension is one that the client may either
engage or ignore, entirely at its discretion, and is signaled by
<code>wsdl:required="false"</code> or the absence of the
<code>wsdl:required</code> attribute (because it defaults to
false). Thus, a WSDL 2.0 processor, acting on behalf of the client,
that encounters an unknown optional extension can safely ignore it
and continue to process the WSDL 2.0 document. However, it is
important to stress that optional extensions are only optional to
the <em>client</em> -- not the service. A service must support all
optional and required extensions that it advertises in its WSDL 2.0
document.</p>
<p>A <em>required</em> extension is one that must be supported and
engaged by the client in order for the interaction to proceed
properly, and is signaled by <code>wsdl:required="true"</code>. If
a WSDL 2.0 processor, acting on behalf of the client, encounters a
required extension that it does not recognize or does not support,
then it cannot safely continue to process the WSDL 2.0 document. In
most practical cases, this is likely to mean that the processor
will require manual intervention to deal with the extension. For
example, a client developer might manually provide an
implementation for the required extension to the WSDL 2.0
processor.</p>
</div>
</div>
<div class="div2">
<h3><a name="adv-MEP" id="adv-MEP"></a>4.2 Defining New MEPs</h3>
<p>As we mentioned in <a href=
"#more-interfaces-meps"><strong>2.4.4.3 Understanding Message
Exchange Patterns (MEPs)</strong></a>, even though the 8 MEPs
defined by WSDL 2.0 are intended to cover most of the common use
cases, there are situations that require new MEPs to be defined. In
this section, we will explain how new MEPs can be defined to
address special business requirements.</p>
<p>Following the wild success of its reservation service, GreatH
discovered that it could radically increase tourist interest by
supplying information on weather conditions, both to travel agents
and to the general touring public. This produced a challenge for
the service implementers: how could this information be supplied to
interested parties without requiring knowledge of web service
technology specifically, and of computers generally? At issue was
the desire to provide asynchronous updates to unsophisticated
customers without incurring onerous overheads for technical
support.</p>
<p>The solution adopted was to create a standard mailing list, and
to make available a small cross-platform web service client
(actually, a subscriber) that could be installed on any computer
with POP or IMAP access to a mailbox. The mailbox, once signed up
for the mailing list, could either be processed as "dedicated" (to
the GreatH weather service; travel agents did this) or as "general
purpose" (in which case the application would only examine those
emails that contained Subject headers associated with the service).
This required development of a binding to email, which is out of
scope for this example, but the resulting WSDL 2.0 was otherwise
quite straightforward.</p>
<p>Note: the email binding in use here supports publish/subscribe,
by supporting the robust-out-only MEP as well as the client/server
style in-out used for subscribing and unsubscribing. Details of
this binding would require a document as long as the primer, so
play along.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"weather-not-initial" id=
"weather-not-initial"></a><em><span>Example 4-1.</span> Weather
Notification Service (Initial)</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;description xmlns="http://www.w3.org/ns/wsdl"
      targetNamespace="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
      xmlns:tns="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
      xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
      xmlns:email="http://www.example.com/webservices/email" &gt;

    &lt;types&gt;
        . . .
    &lt;/types&gt;

    &lt;interface name="weatherInterface"&gt;
        &lt;operation name="opSubscribeWeather"
                   pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
            &lt;input element=". . ." /&gt;
            &lt;output element=". . ." /&gt;
        &lt;/operation&gt;
        &lt;operation name="opUnsubscribeWeather"
                   pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
            &lt;output element=". . ." /&gt;
            &lt;input element=". . ." /&gt;
        &lt;/operation&gt;
        &lt;operation name="opNotifyWeather"
                   pattern="http://www.w3.org/ns/wsdl/robust-out-only"&gt;
            &lt;output element=". . ." /&gt;
        &lt;/operation&gt;
    &lt;/interface&gt;

    &lt;binding name="weatherMailingListBinding"
             interface="tns:weatherInterface
             type="http://www.w3.org/ns/wsdl/soap"
             wsoap:protocol="http://www.example.com/bindings/email"&gt;
             . . .
    &lt;/binding&gt;

    &lt;service name="weatherService"
             interface="tns:weatherInterface"&gt;
        &lt;endpoint name="greatHWeatherList"
                  binding="tns:weatherMailingListBinding"
                  address="mailto:weather-owner@greath.example.com" /&gt;
    &lt;/service&gt;

&lt;/description&gt;
</pre></div>
</div>
<p>Note: in the example, the messageLabels of all input and output
elements have been elided, as they are not necessary to
disambiguate (but note that the order of input and output elements
is not significant).</p>
<p>Unfortunately, the service was soon highjacked for the purpose
of annoyment. Repeatedly, hotels in less salubrious climes, and the
victims of various natural climactic disasters (hurricanes,
tornadoes) found themselves signed up to receive material full of
incomprehensible pointy brackets. They complained to GreatH, who
complained to their service designers.</p>
<p>Applying public key infrastructure to solving the problem was
immediately rejected as too complex and too heavyweight. Analysis
showed that the problem was simply to verify that the address
requesting information actually wanted that information.
Consequently, a new message exchange pattern was defined.</p>
<div class="div3">
<h4><a name="challenge-confirm" id="challenge-confirm"></a>4.2.1
Confirmed Challenge</h4>
<p>This pattern consists of two or more messages in order as
follows:</p>
<ol class="enumar">
<li>
<p>A message:</p>
<ul>
<li>
<p>indicated by a Message Label component whose message label is
"Request" and direction is "in"</p>
</li>
<li>
<p>received from some node N1</p>
</li>
</ul>
</li>
<li>
<p>A message:</p>
<ul>
<li>
<p>indicated by a Message Label component whose message label is
"Challenge" and direction is "out"</p>
</li>
<li>
<p>sent to some node N2 (which <em>may</em> be the same node as
N1)</p>
</li>
</ul>
</li>
<li>
<p>An optional message:</p>
<ul>
<li>
<p>indicated by a Message Label component whose message label is
"Confirmation" and direction is "in"</p>
</li>
<li>
<p>received from node N2</p>
</li>
</ul>
</li>
<li>
<p>An optional message:</p>
<ul>
<li>
<p>indicated by a Message Label component whose message label is
"Response" and direction is "out"</p>
</li>
<li>
<p>sent to node N2</p>
</li>
</ul>
</li>
</ol>
<p>This pattern uses the rule Message Triggers Fault.</p>
<p>An operation using this message exchange pattern has a pattern
property with the value
"http://www.example.com/webservices/meps/confirmed-challenge".</p>
<p>Once the MEP had been defined (and the email binding
specification appropriately modified to indicate that this was a
supported MEP), the service was redefined and redeployed. Only the
changed operations are shown in the excerpt below.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"weather-not-final" id="weather-not-final"></a><em><span>Example
4-2.</span> Weather Notification Service (Revised)</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;description xmlns="http://www.w3.org/ns/wsdl"
      targetNamespace="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
      xmlns:tns="http://greath.example.com/2004/wsdl/weathSvc.wsdl"
      xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
      xmlns:email="http://www.example.com/webservices/email" &gt;

   . . .

    &lt;interface name="weatherInterface"&gt;
        &lt;operation name="opSubscribeWeather"
                   pattern="http://www.example.com/webservices/meps/confirmed-challenge"&gt;
            &lt;input messageLabel="Request" element=". . ." /&gt;
            &lt;output messageLabel="Challenge" element=". . ." /&gt;
            &lt;input messageLabel="Confirmation" element=". . ." /&gt;
            &lt;output messageLabel="Response" element=". . ." /&gt;
        &lt;/operation&gt;
        &lt;operation name="opUnsubscribeWeather"
                   pattern="http://www.example.com/webservices/meps/confirmed-challenge"&gt;
            &lt;output messageLabel="Challenge" element=". . ." /&gt;
            &lt;output messageLabel="Response" element=". . ." /&gt;
            &lt;input messageLabel="Confirmation" element=". . ." /&gt;
            &lt;input messageLabel="Request" element=". . ." /&gt;
        &lt;/operation&gt;
        . . .
    &lt;/interface&gt;

    . . .

&lt;/description&gt;
</pre></div>
</div>
<p>Note: in the second example, the input and output examples are
not in the sequence in which they occur in the pattern; this
illustrates that the sequence is not significant. Note, however,
that for this pattern, the messageLabel attribute is required on
every input and output element.</p>
</div>
</div>
<div class="div2">
<h3><a name="adv-RPCstyle" id="adv-RPCstyle"></a>4.3 RPC Style</h3>
<p>Section <a href="#more-interfaces-op-attr"><strong>2.4.4.1
Operation Attributes</strong></a> mentioned that the (optional)
<code>style</code> attribute of an interface operation is used to
indicate that the operation conforms to a particular pre-defined
operation style, or set of constraints. Actually, if desired the
<code>style</code> attribute can hold a list of URIs, indicating
that the operation simultaneously conforms to multiple styles.</p>
<p>Operation styles are named using URIs, in order to be
unambiguous while still permitted new styles to be defined without
requiring updates to the WSDL 2.0 language. WSDL 2.0 Part 2
[<cite><a href="#WSDL-PART2">WSDL 2.0 Adjuncts</a></cite>] defines
three such operation styles; one of these is the RPC Style
(<a href="http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC
Style</a>).</p>
<p>The <em>RPC Style</em> is designed to facilitate programming
language bindings to WSDL 2.0 constructs. It allows a WSDL 2.0
interface operation to be easily mapped to a method or function
signature, such as a method signature in Java(TM) or C#. RPC Style
is restricted to operations that use the In-Out or In-Only MEPs
(see <a href="#more-interfaces-meps"><strong>2.4.4.3 Understanding
Message Exchange Patterns (MEPs)</strong></a>).</p>
<p>A WSDL 2.0 document makes use of the RPC Style in an interface
operation by first defining the operation in conformance with all
of the RPC Style rules, and then setting that operation's
<code>style</code> attribute to include the URI that identifies the
RPC Style, thus asserting that the operation does indeed conform to
the RPC Style. These rules permit the input and output message
schemas to map conveniently to inputs and outputs of a method
signature. Roughly, input elements map to input parameters, output
elements map to output parameters, and elements that appear both in
the input and output message schemas map to input/output
parameters. WSDL 2.0 Part 2 section "<a href=
"http://www.w3.org/2002/ws/desc/wsdl20-adjuncts#RPCStyle">RPC
Style</a>" provides full details of the mapping rules and
requirements.</p>
<p>The RPC Style also permits the full signature of the intended
mapping to be indicated explicitly, using the
<code>wrpc:signature</code> attribute defined in WSDL 2.0 Part 2
section "<a href=
"http://www.w3.org/2002/ws/desc/wsdl20-adjuncts">wrpc:signature
Extension</a>". This is an (optional) extension to the WSDL 2.0
language whose value designates how input and output message schema
elements map to input and output parameters in the method
signature.</p>
<p>The example below illustrates how RPC Style may be used to
designate a signature. This example is a modified version of the
GreatH reservation service. In particular, the
<code>interface</code> and <code>types</code> sections have been
modified to specify and conform to the RPC Style.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-rpc-style" id="example-rpc-style"></a><em><span>Example
4-3.</span> Specifying RPC Style</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
. . .
&lt;types&gt;

  &lt;xs:element name="checkAvailability"&gt;
    &lt;xs:complexType&gt;
      &lt;xs:sequence&gt;
          &lt;xs:element  name="checkInDate" type="xs:date"/&gt;
          &lt;xs:element  name="checkOutDate" type="xs:date"/&gt;
          &lt;xs:element  name="roomType" type="xs:string"/&gt;
      &lt;/xs:sequence&gt;
    &lt;/xs:complexType&gt;
  &lt;/xs:element&gt;

  &lt;xs:element name="checkAvailabilityResponse"&gt;
    &lt;xs:complexType&gt;
      &lt;xs:sequence&gt;
         &lt;xs:element  name="roomType" type="xs:string"/&gt;
         &lt;xs:element  name="rateType" type="xs:string"/&gt;
         &lt;xs:element  name="rate" type="xs:double"/&gt;
     &lt;/xs:sequence&gt;
    &lt;/xs:complexType&gt;
  &lt;/xs:element&gt;
  . . .
&lt;/types&gt;

&lt;interface  name = "reservationInterface" &gt;

  &lt;operation name="checkAvailability"
        pattern="http://www.w3.org/ns/wsdl/in-out"
        style="http://www.w3.org/ns/wsdl/rpc"
        wrpc:signature=
          "checkInDate #in checkOutDate #in roomType #inout rateType #out rate #return"&gt;
    &lt;input messageLabel="In"
          element="tns:checkAvailability" /&gt;
    &lt;output messageLabel="Out"
          element="tns:checkAvailabilityResponse" /&gt;

  &lt;/operation&gt;
. . .
&lt;/interface&gt;
. . .
</pre></div>
</div>
<p>Note that the interface operation's name
"<code>checkAvailability</code>", is the same as the localPart of
the input element's QName, "<code>tns:checkAvailability</code>".
This is one of the requirements of the RPC Style. The name of the
operation is used as the name of the method in a language binding,
subject to further mapping restrictions specific to the target
programming language. In this case, the name of the method would be
"<code>checkAvailability</code>".</p>
<p>The local children elements of the input element and output
element designate the parameters and the return type for a method
call. Note that the elements <code>checkInDate</code>,
<code>checkOutDate</code> are input parameters, however the element
<code>roomType</code> is an in-out parameter, as it appears both as
a local element child of both input and output elements. This
indicates that the reservation system may change the room type
requested based on availability.</p>
<p>The reservation service also returns a rate type for the
reservation, such as "rack rate". The return value for the method
is designated as the "rate" element.</p>
<p>Based on the value of the <code>wrpc:signature</code> attribute,
the method signature would be obtained following the order of the
parameters. A sample mapping is provided below for the Java(TM)
language. This example was created using JAX RPC 1.1
[<cite><a href="#jaxrpc">JAX RPC 1.1</a></cite>] for mapping simple
types to Java types and designated inout and output parameters by
using Holder classes.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-rpc-style-java-sig" id=
"example-rpc-style-java-sig"></a><em><span>Example 4-4.</span>
Sample Java(TM) Signature for RPC Style</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
public interface reservationInterface extends Remote{

   double checkAvailability(java.util.calendar checkInDate,
              java.util.calendar checkOutDate,
              StringHolder roomType, 
              StringHolder rateType) throws RemoteException; 
    . . .
}
</pre></div>
</div>
<p>Programming languages may further specify how faults are mapped
to language constructs and their scopes, such as Exceptions, but
they are not specific to RPC style.</p>
</div>
</div>
<div class="div1">
<h2><a name="advanced-topic_iv" id="advanced-topic_iv"></a>5.
Advanced Topics III: Miscellaneous</h2>
<p>This section covers various topics that may fall outside the
scope of WSDL 2.0, but shall provide useful background and best
practice guidances that may be useful when authoring a WSDL 2.0
document or implementing the WSDL 2.0 specification.</p>
<div class="div2">
<h3><a name="adv-message-dispatch" id=
"adv-message-dispatch"></a>5.1 Enabling Easy Message Dispatch</h3>
<p>It is desirable for a message recipient to have the capability
to uniquely identify a message type in order to handle it
correctly. The capability of identifying a message type is
typically used for dispatching purposes within an implementation of
a web service. Therefore, WSDL authors are recommended to consider
how to disambiguate message types when they develop their
services.</p>
<p>The context in which a Web service may be deployed plays an
important role in choosing an appropriate way to disambiguate and
identify message types. In a typical deployment, an endpoint
address may host a single service that is described by a WSDL
service element. In this case, when XSD is used, assigning unique
qualified names of global element declarations as inputs within the
interface that describes the service would be sufficient to
disambiguate the types of the messages that are received. However,
when endpoint address hosts multiple services, in essence
supporting several WSDL descriptions, the desire to disambiguate
message types should be considered within the context of all the
deployed services, not only within a single interface.</p>
<p>As explained in <a href=
"#more-interfaces-op-attr"><strong>2.4.4.1 Operation
Attributes</strong></a>, when XSD is used as the type system, a few
special tokens can be used for the <code>element</code> attributes.
Uniquely identifying a message type may become very difficult
when:</p>
<ul>
<li>
<p>any of these input elements within an interface has a value of
"#any"; or</p>
</li>
<li>
<p>more than one of these input elements (see below) has a value of
"#none"; or</p>
</li>
<li>
<p>the qualified names of the global element declarations that are
specified as input elements are NOT unique when considered
together.</p>
</li>
</ul>
<p>If any of the three cases above arise, disambiguation mechanisms
may be provided by means of an extension element (i.e., an element
that is not in the http://www.w3.org/ns/wsdl namespace), having a
wsdl:required attribute with a value of "true". The semantics of
such an extension element would indicate the mechanism for
unambiguously identifing the mechanism that a message sender is
required to support in order to enable the message recipient to
unambiguously determine the message received.</p>
<p>For example, the WS-Addressing [<cite><a href=
"#WS-A">WS-Addressing</a></cite>] specification provides such a
disambiguation mechanism. It consists of an extension element which
may be marked as required, and defines a required [action] property
whose value is always present in a conformant message delivery. The
value of the action property can be used to disambiguate the
message by the receiver and there is a well defined way to
associate actions to messages in WS-Addressing specifications.
Further, WS-Addressing also provides an appropriate default action
value that identifies each message type uniquely.</p>
<p>When using the HTTP Binding, or when using the SOAP Binding with
the SOAP Response MEP, there is no SOAP envelope in a request
message, and thus mechanisms other than unique qualified names of
global element declarations, or headers such as wsa:Action, must be
considered. In these cases, the {address} and {http location}
properties may be constructed so as to provide a location that can
be correlated uniquely with an operation. For instance, one could
prefix the {http location} property with the operation name, or one
could ensure that the portion of the {http location} preceding the
first unescaped "{" character be unique per operation.</p>
</div>
<div class="div2">
<h3><a name="adv-versioning" id="adv-versioning"></a>5.2 Web
Service Versioning</h3>
<p>A WSDL 2.0 document describes a set of messages that a Web
service may send and receive. In essence, it describes a language
for interacting with that service. However it is possible for a Web
service to exchange other messages beyond those described in a
particular WSDL 2.0 document. Often this circumstance occurs
following an evolution of the client and/or service, and thus an
evolution of the interaction language.</p>
<p>How best to manage the evolution (versioning) of Web based
systems is, at the time of writing, the subject of a wide-ranging
debate. However, there are three activities within the W3C that are
directly relevant to versioning of Web services description:</p>
<ul>
<li>
<p>The <a href="http://www.w3.org/2001/tag/">Technical Architecture
Group (TAG)</a> has published guidance on the extensibility and
versioning of data formats in its Web Architecture document
[<cite><a href="#webarch">Web Architecture</a></cite>]. There is
also a more wide ranging draft finding on Versioning and
Extensibility [<cite><a href="#TAG-versioning">W3C TAG Finding:
Extending and Versioning Languages Part 1</a></cite>]. Both of
these works build upon the technical note on Web Architecture:
Extensible Languages [<cite><a href="#web-extensible">WebArch:
Extensible Languages</a></cite>].</p>
</li>
<li>
<p>The <a href="http://www.w3.org/XML/Schema">XML Schema Working
Group</a> is collecting a series of use cases for schema versioning
as a part of the Schema 1.1 activity. See XML Schema Versioning Use
Cases [<cite><a href="#xsd-versioning">XML Schema: Versioning
Use-Cases</a></cite>].</p>
</li>
<li>
<p>The Guide to Versioning XML Languages using XML Schema 1.1
[<cite><a href="#xsd-versioning-guide">Guide to Versioning XML
Languages using XML Schema 1.1</a></cite>] illustrates some
techniques for versioning XML languages enabled by features of XML
Schema 1.1 [<cite><a href="#xsd11">XML Schema 1.1</a></cite>].</p>
</li>
<li>
<p>The <a href="http://www.w3.org/2001/sw/BestPractices/">Semantic
Web Best Practices and Deployments Working Group</a> is examining
how vocabularies may evolve. See [<cite><a href="#sw-vocabulary">SW
VocabManagementNote</a></cite>]</p>
</li>
</ul>
<p>While incomplete, these activities all agree in one important
respect: that versioning is difficult, but you should anticipate
and plan for change.</p>
<p>The draft finding on Versioning and Extensibility details two
key approaches to versioning:</p>
<ul>
<li>
<p>compatible evolution; and</p>
</li>
<li>
<p>big bang.</p>
</li>
</ul>
<div class="div3">
<h4><a name="adv-versioning-compatible-evolution" id=
"adv-versioning-compatible-evolution"></a>5.2.1 Compatible
Evolution</h4>
<p>In <em>compatible evolution</em>, designers are expected to
limit changes to those that are either backward or forward
compatible, or both:</p>
<dl>
<dt class="label">Backward compatible</dt>
<dd>
<p>The receiver behaves correctly if it receives a message in an
<em>older</em> version of the interaction language.</p>
</dd>
<dt class="label">Forward compatible</dt>
<dd>
<p>The receiver behaves correctly if it receives a message in a
<em>newer</em> version of the interaction language.</p>
</dd>
</dl>
<p>Since Web services and their clients both send and receive
messages, these concepts can apply to both parties. However, since
WSDL 2.0 is service-centric, we will focus on the case of service
evolution.</p>
<p>There are three critical areas in which a service described in
WSDL 2.0 my evolve:</p>
<ul>
<li>
<p>The service now also supports additional binding. In compatible
evolution, this should be a safe addition, given that adding a new
binding should not impact any existing interactions using another
transport.</p>
</li>
<li>
<p>An interface supports new operations. Again, in compatible
evolution this is usually safe, given that adding an additional
operation to an abstract interface should not impact any existing
interactions.</p>
</li>
<li>
<p>The message bodies may include additional data. How the message
contents may change within a description depends to a large extent
upon the type system being used to describe the message contents.
RelaxNG [<cite><a href="#relax-ng">RELAX NG</a></cite>] has good
support for describing vocabularies that ignore unknown XML, as
does OWL/RDF. XML Schema 1.0 has limited support for extending the
description of a message via the <code>xs:any</code> and
<code>xs:anyAttribute</code> constructs. XML Schema 1.1 has been
chartered to provide "changes necessary to provide better support
for versioning of schemas", and it is anticipated that this may
include improved support for more "open content" and therefore
better support for compatible evolution of messages.</p>
</li>
<li>
<p>The protocol used to exchange messages may provide mechanisms
for exchanging data outside of the message body. In the case of
SOAP, the WSDL 2.0 binding provides the ability to describe
application data to be exchanged as headers. The SOAP processing
model has a very good extensibility model with unknown headers
being ignored by a receiver by default. There is also a mechanism
whereby headers which are required as a part of an incompatible
change may be marked with a 'mustUnderstand' flag. Passing
additional items as headers may be the only way to compatibly
evolve messages with fixed bodies.</p>
</li>
</ul>
</div>
<div class="div3">
<h4><a name="adv-versioning-big-bang" id=
"adv-versioning-big-bang"></a>5.2.2 Big Bang</h4>
<p>The <em>big bang</em> approach to versioning is the simplest to
currently represent in WSDL 2.0. In this approach, any change to a
WSDL 2.0 document implies a change to the document's namespace, a
change to the interface implies a new interface namespace and a
change to the message contents is communicated using a new message
namespace. This approach has particular benefits where an agent may
quickly tell if a service has changed by simply comparing the
namespace value.</p>
</div>
<div class="div3">
<h4><a name="ad-versioing-migration" id=
"ad-versioing-migration"></a>5.2.3 Evolving a Service</h4>
<p>Compatible changes are far more easily managed than incompatible
ones:</p>
<ul>
<li>
<p>With a compatible change the service need only support the
latest version of a service. A client may continue to use a service
adjusting to new version of the interface description at a time of
its choosing.</p>
</li>
<li>
<p>With an incompatible change, the client receives a new version
of the interface description and is expected to adjust to the new
interface before old interface is terminated. Either the service
will need to continue to support both versions of the interface
during the hand over period, or the service and the clients are
coordinated to change at the same time. An alternative is for the
client to continue until it encounters an error, at which point it
uses the new version of the interface.</p>
</li>
</ul>
</div>
<div class="div3">
<h4><a name="adv-versioning-combined" id=
"adv-versioning-combined"></a>5.2.4 Combined Approaches</h4>
<p>It is feasible to combine the "compatible evolution" and "big
bang" approaches in a variety of different ways. For example, the
namespace could be changed when message descriptions are changed,
but the namespace could stay the same when new operations are
added.</p>
<p>While the big bang approach is currently the easiest to
implement in WSDL 2.0, it can lead to a large number of cloned
interfaces that become difficult to manage, thus making the
compatible approach preferable to many for widely distributed
systems. In the end, the choice of a versioning strategy for Web
services described in WSDL 2.0 is left as an exercise to the
reader.</p>
</div>
<div class="div3">
<h4><a name="adv-versioning-examples" id=
"adv-versioning-examples"></a>5.2.5 Examples of Versioning and
Extending a Service</h4>
<div class="div4">
<h5><a name="id2301152" id="id2301152"></a>5.2.5.1 Additional
Optional Elements Added in Content</h5>
<p>The following example demonstrates how content may be extended
with additional content. The reservation service is changed to a
newer version that can accept an optional number of guests
parameter. The service provider wants existing clients to continue
to be able to use the service. The author adds the element into the
schema as an optional element.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-versioning-additional-elements" id=
"example-versioning-additional-elements"></a><em><span>Example
5-1.</span> XML Schema with Optional Elements</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;xs:complexType name="tCheckAvailability"&gt;     
    &lt;xs:sequence&gt;      
      &lt;xs:element  name="checkInDate" type="xs:date"/&gt;      
      &lt;xs:element  name="checkOutDate" type="xs:date"/&gt;      
      &lt;xs:element  name="roomType" type="xs:string"/&gt;
      &lt;xs:element  name="numberOfGuests" type="xs:integer" minOccurs="0"/&gt;
      &lt;xs:any namespace="##other" processContents="lax"/&gt;
    &lt;/xs:sequence&gt;
&lt;/xs:complexType&gt;     
        
</pre></div>
</div>
<p>The author has the choice of keeping the same namespace or using
a different namespace for the additional content and the existing
content. In this scenario, it is a compatible change and the author
decides to keep the same namespace. This allows existing clients to
interact with a new service, and it allows newer clients to
interact with older services.</p>
</div>
<div class="div4">
<h5><a name="id2301217" id="id2301217"></a>5.2.5.2 Additional
Optional Elements Added to a Header</h5>
<p>Another option is to add the extension as a header block. This
is accomplished by defining an element for the extension and adding
a header element that references the element into the binding
operation as child of the input.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-versioning-additional-header-elements" id=
"example-versioning-additional-header-elements"></a><em><span>Example
5-2.</span> Additional optional elements added to a SOAP
header</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;xs:element name="NumberOfGuests" type="tNumberOfGuests"/&gt;
&lt;xs:complexType name="tNumberOfGuests"&gt;     
    &lt;xs:sequence&gt;      
        &lt;xs:element  name="numberOfGuests" type="xs:integer" minOccurs="0"/&gt;
    &lt;/xs:sequence&gt;
&lt;/xs:complexType&gt;

&lt;binding name="reservationSOAPBinding" 
    interface="tns:reservationInterface"
    type="http://www.w3.org/ns/wsdl/soap"
    wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"&gt;

    &lt;operation ref="tns:opCheckAvailability"&gt;
       &lt;input&gt;
         &lt;wsoap:header element="tns:NumberOfGuests"/&gt;
       &lt;/input&gt;
    &lt;/operation&gt;
...
&lt;/binding&gt;
    
</pre></div>
</div>
<p>It is also possible for the header to be marked with
soap:mustUnderstand set to true. The HTTP Binding has similar
functionality though without a mustUnderstand attribute.</p>
</div>
<div class="div4">
<h5><a name="id2301271" id="id2301271"></a>5.2.5.3 Additional
Mandatory Elements in Content</h5>
<p>This following example demonstrates an extension with additional
content. The reservation service requires a number of guests
parameter. The service provider wants existing clients to be unable
to use the service. The author adds the element into the schema as
a mandatory element.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-versioning-additional-mandatory-elements" id=
"example-versioning-additional-mandatory-elements"></a><em><span>Example
5-3.</span> Additional Mandatory Elements in Content</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;xs:complexType name="tCheckAvailabilityV2"&gt;     
    &lt;xs:sequence&gt;      
    &lt;xs:element  name="checkInDate" type="xs:date"/&gt;      
    &lt;xs:element  name="checkOutDate" type="xs:date"/&gt;      
    &lt;xs:element  name="roomType" type="xs:string"/&gt;
    &lt;xs:element  name="numberOfGuests" type="xs:integer"/&gt;
    &lt;xs:any namespace="##other" processContents="lax"/&gt;
    &lt;/xs:sequence&gt;
&lt;/xs:complexType&gt;     
            
</pre></div>
</div>
<p>The author has the choice of keeping the same namespace or using
a different namespace for the additional content and the existing
content. In this scenario, it is an incompatible change and the
author decides to use a new name but the same namespace. This type
is then used in the interface operation, and then binding and
service endpoints.</p>
</div>
<div class="div4">
<h5><a name="id2301354" id="id2301354"></a>5.2.5.4 Additional
Optional Operation Added to Interface</h5>
<p>Section <a href="#more-interfaces-inheritance"><strong>2.4.2
Interface Inheritance</strong></a> shows another type of versioning
or extension, where the reservationInterface extends the
MessageLogInterface. By definition of interface inheritance, a
client that understands just the MessageLogInterface will continue
to work with the reservationInterface, that it is backwards
compatible.</p>
</div>
<div class="div4">
<h5><a name="id2301385" id="id2301385"></a>5.2.5.5 Additional
Mandatory Operation Added to Interface</h5>
<p>Often mandatory operations are added to an interface. The Hotel
service decides to add an operation to the reservation service
which is a confirmation. The Hotel service requires that all
clients upgrade to the new interface to use the service. They have
a variety of options for indicating that the old interface is
deprecated.</p>
<p>By the definition of interface inheritance, they cannot use
interface inheritance for defining the extension.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-versioning-additional-mandatory-operation" id=
"example-versioning-additional-mandatory-operation"></a><em><span>Example
5-4.</span> Additional Mandatory Operation Added to the
Interface</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;interface name="reservationWithConfirmation" extends="cc:creditCardFaults"&gt;
    ... 
    &lt;operation name="makeReservation"&gt;
        &lt;input messageLabel="In" element="ghns:makeReservation" /&gt;
        &lt;output messageLabel="Out" element="ghns:makeReservationResponse" /&gt;
        &lt;outfault ref="invalidDataFault" messageLabel="Out" /&gt;
        &lt;outfault ref="cc:cancelledCreditCard" messageLabel="Out" /&gt;
        &lt;outfault ref="cc:expiredCreditCard" messageLabel="Out" /&gt;
        &lt;outfault ref="cc:invalidCreditCardNumber" messageLabel="Out" /&gt;
        &lt;outfault ref="cc:invalidExpirationDate" messageLabel="Out" /&gt;
    &lt;/operation&gt;
    &lt;operation name="confirmReservation"&gt;
        &lt;input messageLabel="In" element="ghns:makeReservationResponse" /&gt;
        &lt;output messageLabel="Out" element="ghns:confirmReservationResponse" /&gt;
        &lt;outfault ref="expiredReservation" messageLabel="Out" /&gt;
    &lt;/operation&gt;
&lt;/interface&gt;
            
</pre></div>
</div>
<p>This interface cannot be bound and deployed at the existing URI
and indicate incompatibility, as the service will still accept the
makeReservation request. Changing the name of the interface from
reservation to reservationWithConfirmation or changing the name of
the operation from makeReservation to makeReservationV2 does not
affect the messages that are exchanged. Thus it can't be used as a
mechanism for indicating incompatibility. To indicate
incompatibility, a change must be made to something that appears in
the message. For a SOAP over HTTP request, the list is roughly the
URI, the SOAP Action HTTP Header, or the Message content.</p>
</div>
<div class="div4">
<h5><a name="id2301454" id="id2301454"></a>5.2.5.6 Indicating
Incompatibility by Changing the Endpoint URI</h5>
<p>To indicate incompatibility, the URI of the Hotel Endpoint can
be changed and messages send to the old Endpoint return a
Fault.</p>
</div>
<div class="div4">
<h5><a name="id2301490" id="id2301490"></a>5.2.5.7 Indicating
Incompatibility by Changing the SOAP Action</h5>
<p>The SOAP Action can be set for the makeReservation request, and
making it different than the earlier version should indicate
incompatibility.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-versioning-SOAP-Action" id=
"example-versioning-SOAP-Action"></a><em><span>Example 5-5.</span>
Indicating Incompatibility by changing the SOAP Action</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;binding name="reservationSOAPBinding" 
        interface="tns:reservationInterface"
        type="http://www.w3.org/ns/wsdl/soap"
        wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"&gt;
    &lt;operation ref="tns:makeReservation"
        wsoap:action="tns:makeReservationV2"/&gt;
    . . .
            
</pre></div>
</div>
<p>Note that this mechanism is applicable on a per-binding basis.
The SOAP HTTP Binding provides for setting Action, but other
bindings may not provide such a facility.</p>
</div>
<div class="div4">
<h5><a name="id2301552" id="id2301552"></a>5.2.5.8 Indicating
Incompatibility by Changing the Element Content</h5>
<p>The namespace or name of the makeReservation element can be
changed, and then the interface and bindings changed. To indicate
incompatibility, requests using the old makeReservation QName
should probably return a fault. The new interface, with a changed
makeReservation, is:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example-versioning-changing-element-content" id=
"example-versioning-changing-element-content"></a><em><span>Example
5-6.</span> Indicating incompatibility by changing the element
content</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;xs:element name="ghns2:makeReservation" type="ghns:tmakeReservation"/&gt;

&lt;interface . . .&gt;

   &lt;operation name="makeReservation"&gt;

       &lt;input messageLabel="In" element="ghns2:makeReservation" /&gt;

&lt;/interface&gt;
    
</pre></div>
</div>
<p>The binding and service endpoints require no change.</p>
<p>Finally, the service could also provide an interface for
ghns:makeReservation that only returns a fault.</p>
</div>
</div>
</div>
<div class="div2">
<h3><a name="adv-service-references" id=
"adv-service-references"></a>5.3 Describing Web Service Messages
That Refer to Other Web Services</h3>
<p>Hyperlinking is one of the defining characteristics of the Web.
The ability to navigate from one Web page to another is extremely
useful. It is therefore natural to apply this capability to Web
services. This section describes references to endpoints and
services, which are the Web service analogs of document
hyperlinks.</p>
<p>A <em>reference to an endpoint</em> is an element or attribute
that contains the address of a Web service endpoint. A
<em>reference to a service</em> is an element or attribute that
contains one or more references to the endpoints of a service. If
the interface or binding that the service or endpoint implements is
known at description time, it may be useful to add this information
to the WSDL 2.0 document that describes the Web service. This is
accomplished by using the <code>wsdlx:interface</code> or
<code>wsdlx:binding</code> attribute to annotate the XML Schema
component that defines the message.</p>
<p>One may wonder, from a Web architectural point of view, why
anything more than a URI would be needed to reference a Web
service. Indeed, a reference to a service does make use of one or
more URIs to indicate the endpoint addresses of a service. However,
it may also include additional metadata about that service, such as
the WSDL 2.0 interface and binding that the service supports.</p>
<p>References to services and endpoints will be illustrated by
expanding the GreatH example already discussed.</p>
<div class="div3">
<h4><a name="reservationDetails" id="reservationDetails"></a>5.3.1
The Reservation Details Web Service</h4>
<p>When designing a Web application it is natural to give each
important concept a URI. In the GreatH hotel reservation system,
the important concepts are reservations, so we begin our design by
assigning a URI to each reservation. Since each reservation has a
unique confirmation number, e.g OMX736, we create a URI for each
reservation by appending the confirmation number to a base URI,
e.g. http://greath.example.com/2004/reservation/OMX736. This URI
will be the endpoint address for a Reservation Details Web service
that can retrieve and update the state of a reservation. <a href=
"#reservationDetails-OMX736.xml">Example 5-7</a> shows the format
of the reservation detail.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"reservationDetails-OMX736.xml" id=
"reservationDetails-OMX736.xml"></a><em><span>Example 5-7.</span>
Detail for Reservation OMX736</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;reservationDetails
        xmlns="http://greath.example.com/2004/schemas/reservationDetails"&gt;

        &lt;confirmationNumber&gt;OMX736&lt;/confirmationNumber&gt;
        &lt;checkInDate&gt;2005-06-01&lt;/checkInDate&gt;
        &lt;checkOutDate&gt;2005-06-03&lt;/checkOutDate&gt;
        &lt;roomType&gt;single&lt;/roomType&gt;
        &lt;smoking&gt;false&lt;/smoking&gt;

&lt;/reservationDetails&gt;
</pre></div>
</div>
<p>The Reservation Details Web service provides operations for
retrieving and updating the detail for a reservation. <a href=
"#reservationDetails.wsdl">Example 5-8</a> shows the description
for this Web service. Note that there is no <code>service</code>
element in this description since the set of reservations is
dynamic. Instead, the endpoints for the reservations will be
returned by querying the Reservation List Web service.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"reservationDetails.wsdl" id=
"reservationDetails.wsdl"></a><em><span>Example 5-8.</span> The
Reservation Details Web Service Description:
reservationDetails.wsdl</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;description 
        xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/reservationDetails"
        xmlns:tns="http://greath.example.com/2004/services/reservationDetails"
        xmlns:wdetails="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

        &lt;documentation&gt;
                This document describes the GreatH Reservation Details Web
                services. Use these services to retrieve or update reservation
                details. Each reservation has its own service and endpoint. To
                obtain the reference for a reservation service, make a request to
                the GreatH Reservation List Web service. See
                reservationList.wsdl for a description of the Reservation List
                Web service.
        &lt;/documentation&gt;

        &lt;types&gt;
                &lt;xs:import
                        namespace="http://greath.example.com/2004/schemas/reservationDetails"
                        schemaLocation="reservationDetails.xsd" /&gt;
        &lt;/types&gt;

        &lt;interface name="reservationDetailsInterface"&gt;

                &lt;operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In" element="#none" /&gt;
                        &lt;output messageLabel="Out"
                                element="wdetails:reservationDetails" /&gt;
                &lt;/operation&gt;

                &lt;operation name="update"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In"
                                element="wdetails:reservationDetails" /&gt;
                        &lt;output messageLabel="Out"
                                element="wdetails:reservationDetails" /&gt;
                &lt;/operation&gt;

        &lt;/interface&gt;

        &lt;binding name="reservationDetailsSOAPBinding"
                interface="tns:reservationDetailsInterface"
                type="http://www.w3.org/ns/wsdl/soap"
                wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"&gt;

                &lt;operation ref="tns:retrieve"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" /&gt;

                &lt;operation ref="tns:update"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" /&gt;

        &lt;/binding&gt;

&lt;/description&gt;
</pre></div>
</div>
<p><a href="#reservationDetails.xsd">Example 5-9</a> shows the XML
schema elements that are used in this Web service.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"reservationDetails.xsd" id=
"reservationDetails.xsd"></a><em><span>Example 5-9.</span> The
Reservation Details Web Service XML Schema:
reservationDetails.xsd</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;schema xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified"
        targetNamespace="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:tns="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:wdetails="http://greath.example.com/2004/services/reservationDetails"
        xmlns:wsdli="http://www.w3.org/ns/wsdl-instance"
        xmlns:wsdlx="http://www.w3.org/ns/wsdl-extensions"
        wsdli:wsdlLocation="http://greath.example.com/2004/services/reservationDetails reservationDetails.wsdl"&gt;

        &lt;element name="confirmationNumber" type="string" /&gt;

        &lt;element name="checkInDate" type="date" /&gt;

        &lt;element name="checkOutDate" type="date" /&gt;

        &lt;element name="reservationDetails"&gt;
                &lt;complexType&gt;
                        &lt;sequence&gt;
                                &lt;element ref="tns:confirmationNumber" /&gt;
                                &lt;element ref="tns:checkInDate" /&gt;
                                &lt;element ref="tns:checkOutDate" /&gt;
                                &lt;element name="roomType" type="string" /&gt;
                                &lt;element name="smoking" type="boolean" /&gt;
                        &lt;/sequence&gt;
                &lt;/complexType&gt;
        &lt;/element&gt;

        &lt;simpleType name="reservationDetailsSOAPEndpointType" wsdlx:binding="wdetails:reservationDetailsSOAPBinding"&gt;
                &lt;restriction base="anyURI"/&gt;
        &lt;/simpleType&gt;

        &lt;element name="reservationDetailsSOAPEndpoint" type="tns:reservationDetailsSOAPEndpointType" /&gt;

        &lt;element name="reservationDetailsService"&gt;
                &lt;annotation&gt;
                        &lt;documentation&gt;
                                This element contains references to the Reservation
                                Details Web Service endpoints for this reservation.
                        &lt;/documentation&gt;
                &lt;/annotation&gt;
                &lt;complexType&gt;
                        &lt;sequence&gt;
                                &lt;element name="soap" type="tns:reservationDetailsSOAPEndpointType"/&gt;
                                &lt;element name="secure-soap" type="tns:reservationDetailsSOAPEndpointType"/&gt;
                        &lt;/sequence&gt;
                &lt;/complexType&gt;
        &lt;/element&gt;

&lt;/schema&gt;
</pre></div>
</div>
<p>This XML schema contains the usual definitions for the elements
that appear in the messages of the Web service. For example, the
<code>reservationDetails</code> element is used in the messages of
the <code>retrieve</code> and <code>update</code> operations. In
addition, the schema defines the simple type
<code>reservationDetailsSOAPEndpointType</code> which is based on
<code>xs:anyURI</code> and has the annotation <code>wsdlx:binding =
"wdetails:reservationDetailsSOAPBinding"</code> which means that
the URI is the address of a Reservation Details Web service
endpoint that implements the
<code>wdetails:reservationDetailsSOAPBinding</code> binding. Note
that the <code>wsdli:wsdlLocation</code> attribute is used to
define the location of the WSDL 2.0 document that defines the
<code>wdetails:reservationDetailsSOAPBinding</code> binding. This
annotated simple type is used to define the
<code>reservationDetailsSOAPEndpoint</code> element which will be
used in the Reservation List service.</p>
</div>
<div class="div3">
<h4><a name="reservationList" id="reservationList"></a>5.3.2 The
Reservation List Web Service</h4>
<p>Since the set of reservations changes as reservations are made
and cancelled, the Reservation Detail endpoints are not described
in a fixed WSDL 2.0 document. Instead they are returned as
references to endpoints in response to requests made on a
Reservation List Web service. The endpoint address for the
Reservation List service will be
http://greath.example.com/2004/reservationList.</p>
<p><a href="#reservationList-all.xml">Example 5-10</a> shows the
format of the response from the Reservation List service.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"reservationList-all.xml" id=
"reservationList-all.xml"></a><em><span>Example 5-10.</span>
Response from the Reservation List Web Service</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;reservationList
        xmlns="http://greath.example.com/2004/schemas/reservationList"
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"&gt;

        &lt;reservation&gt;
                &lt;details:confirmationNumber&gt;HSG635&lt;/details:confirmationNumber&gt;
                &lt;details:checkInDate&gt;2005-06-27&lt;/details:checkInDate&gt;
                &lt;details:checkOutDate&gt;2005-06-28&lt;/details:checkOutDate&gt;
                &lt;details:reservationDetailsSOAPEndpoint&gt;
                        http://greath.example.com/2004/reservation/HSG635
                &lt;/details:reservationDetailsSOAPEndpoint&gt;
        &lt;/reservation&gt;

        &lt;reservation&gt;
                &lt;details:confirmationNumber&gt;OMX736&lt;/details:confirmationNumber&gt;
                &lt;details:checkInDate&gt;2005-06-01&lt;/details:checkInDate&gt;
                &lt;details:checkOutDate&gt;2005-06-03&lt;/details:checkOutDate&gt;
                &lt;details:reservationDetailsSOAPEndpoint&gt;
                        http://greath.example.com/2004/reservation/OMX736
                &lt;/details:reservationDetailsSOAPEndpoint&gt;
        &lt;/reservation&gt;

        &lt;reservation&gt;
                &lt;details:confirmationNumber&gt;WUH663&lt;/details:confirmationNumber&gt;
                &lt;details:checkInDate&gt;2005-06-11&lt;/details:checkInDate&gt;
                &lt;details:checkOutDate&gt;2005-06-15&lt;/details:checkOutDate&gt;
                &lt;details:reservationDetailsSOAPEndpoint&gt;
                        http://greath.example.com/2004/reservation/WUH663
                &lt;/details:reservationDetailsSOAPEndpoint&gt;
        &lt;/reservation&gt;

&lt;/reservationList&gt;
</pre></div>
</div>
<p>Here, the
<code>&lt;details:reservationDetailsSOAPEndpoint&gt;</code>
elements contain references to the Reservation Details Web service
endpoints for the reservations HSG635, OMX736, and WUH663.</p>
<p><a href="#reservationList.wsdl">Example 5-11</a> shows the
description of the Reservation List Web service. Note that it
contains operations to retrieve the entire list and to query for a
list of reservations by confirmation number, check-in date, and
check-out date. In each case, the operation returns a list of
reservations.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"reservationList.wsdl" id=
"reservationList.wsdl"></a><em><span>Example 5-11.</span> The
Reservation List Web Service Description:
reservationList.wsdl</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;description 
        xmlns="http://www.w3.org/ns/wsdl"
        targetNamespace="http://greath.example.com/2004/services/reservationList"
        xmlns:tns="http://greath.example.com/2004/services/reservationList"
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:list="http://greath.example.com/2004/schemas/reservationList"
        xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

        &lt;documentation&gt;
                This document describes the GreatH Reservation List Web
                services. Use this service to retrieve lists of reservations
                based on a variety of search criteria.
        &lt;/documentation&gt;

        &lt;types&gt;
                &lt;xs:import
                        namespace="http://greath.example.com/2004/schemas/reservationDetails"
                        schemaLocation="reservationDetails.xsd" /&gt;
                &lt;xs:import
                        namespace="http://greath.example.com/2004/schemas/reservationList"
                        schemaLocation="reservationList.xsd" /&gt;
        &lt;/types&gt;

        &lt;interface name="reservationListInterface"&gt;

                &lt;operation name="retrieve"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In" element="#none" /&gt;
                        &lt;output messageLabel="Out" element="list:reservationList" /&gt;
                &lt;/operation&gt;

                &lt;operation name="retrieveByConfirmationNumber"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In"
                                element="details:confirmationNumber" /&gt;
                        &lt;output messageLabel="Out" element="list:reservationList" /&gt;
                &lt;/operation&gt;

                &lt;operation name="retrieveByCheckInDate"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In" element="details:checkInDate" /&gt;
                        &lt;output messageLabel="Out" element="list:reservationList" /&gt;
                &lt;/operation&gt;

                &lt;operation name="retrieveByCheckOutDate"
                        pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
                        &lt;input messageLabel="In" element="details:checkOutDate" /&gt;
                        &lt;output messageLabel="Out" element="list:reservationList" /&gt;
                &lt;/operation&gt;

        &lt;/interface&gt;

        &lt;binding name="reservationListSOAPBinding"
                interface="tns:reservationListInterface"
                type="http://www.w3.org/ns/wsdl/soap"
                wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"&gt;

                &lt;operation ref="tns:retrieve"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" /&gt;

                &lt;operation ref="tns:retrieveByConfirmationNumber"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" /&gt;

                &lt;operation ref="tns:retrieveByCheckInDate"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" /&gt;

                &lt;operation ref="tns:retrieveByCheckOutDate"
                        wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" /&gt;

        &lt;/binding&gt;

        &lt;service name="reservationListService"
                interface="tns:reservationListInterface"&gt;

                &lt;endpoint name="reservationListEndpoint"
                        binding="tns:reservationListSOAPBinding"
                        address="http://greath.example.com/2004/reservationList" /&gt;

        &lt;/service&gt;

&lt;/description&gt;
</pre></div>
</div>
<p><a href="#reservationList.xsd">Example 5-12</a> shows the schema
for the messages used in the Reservation List Web service.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"reservationList.xsd" id=
"reservationList.xsd"></a><em><span>Example 5-12.</span> The
Reservation List Schema: reservationList.xsd</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;schema xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified"
        targetNamespace="http://greath.example.com/2004/schemas/reservationList"
        xmlns:tns="http://greath.example.com/2004/schemas/reservationList"
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"
        xmlns:wsdli="http://www.w3.org/ns/wsdl-instance"&gt;

        &lt;import
                namespace="http://www.w3.org/ns/wsdl-instance" /&gt;

        &lt;import
                namespace="http://greath.example.com/2004/schemas/reservationDetails"
                schemaLocation="reservationDetails.xsd" /&gt;

        &lt;element name="reservation"&gt;
                &lt;annotation&gt;
                        &lt;documentation&gt;
                                A reservation contains the confirmation number, check-in
                                and check-out dates, and a reference to a Reservation
                                Details Web service.
                        &lt;/documentation&gt;
                &lt;/annotation&gt;
                &lt;complexType&gt;
                        &lt;sequence&gt;
                                &lt;element ref="details:confirmationNumber" /&gt;
                                &lt;element ref="details:checkInDate" /&gt;
                                &lt;element ref="details:checkOutDate" /&gt;
                                &lt;element ref="details:reservationDetailsSOAPEndpoint" /&gt;
                        &lt;/sequence&gt;
                &lt;/complexType&gt;
        &lt;/element&gt;

        &lt;element name="reservationList"&gt;
                &lt;annotation&gt;
                        &lt;documentation&gt;
                                A reservation list contains a sequence of zero or more
                                reservations.
                        &lt;/documentation&gt;
                &lt;/annotation&gt;
                &lt;complexType&gt;
                        &lt;sequence&gt;
                                &lt;element ref="tns:reservation" minOccurs="0"
                                        maxOccurs="unbounded"&gt;
                                &lt;/element&gt;
                        &lt;/sequence&gt;
                        &lt;attribute ref="wsdli:wsdlLocation" /&gt;
                &lt;/complexType&gt;
        &lt;/element&gt;

&lt;/schema&gt;
</pre></div>
</div>
<p>In the preceding example, there was a single endpoint associated
with each Reservation Detail Web service. Suppose GreatH hotel
decided to provide a second, secure endpoint. In this case,
references to services would be used to collect together the
endpoints for each reservation. The reservationDetails.xsd schema
defines the <code>reservationDetailsService</code> element for this
purpose. It contains the nested elements <code>soap</code> and
<code>secure-soap</code> which are each of type
<code>reservationDetailsSOAPEndpointType</code> and therefore
contain the address of an endpoint that implements the
<code>wdetails:reservationDetailsSOAPBinding</code> binding.</p>
<p><a href="#reservationServiceReferences-HSG635.xml">Example
5-13</a> shows an example of a message that contains a reference to
the service for reservation HGS635. Note that the service contains
two endpoints, one of which provides secure access to the
Reservation Details Web service.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"reservationServiceReferences-HSG635.xml" id=
"reservationServiceReferences-HSG635.xml"></a><em><span>Example
5-13.</span> A Reference to the Reservation Details Web
Service</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;details:reservationDetailsService
        xmlns:details="http://greath.example.com/2004/schemas/reservationDetails"

        &lt;details:soap&gt;
                http://greath.example.com/2004/reservation/HSG635
        &lt;/details:soap&gt;

        &lt;details:secure-soap&gt;
                https://greath.example.com/2004/reservation/HSG635
        &lt;/details:secure-soap&gt;
                        
&lt;/details:reservationDetailsService&gt;
</pre></div>
</div>
</div>
<div class="div3">
<h4><a name="reservationDetails_HTTP" id=
"reservationDetails_HTTP"></a>5.3.3 Reservation Details Web Service
Using HTTP Transfer</h4>
<p>This section presents a variation on the example in <a href=
"#reservationDetails"><strong>5.3.1 The Reservation Details Web
Service</strong></a> . It illustrates the use of HTTP transfer
operations, GET and PUT, to retrieve and update GreatH hotel
reservation details using the Representational State Transfer
(REST) architectural style described by Roy Fielding
[<cite><a href="#rest">REST</a></cite>] . REST is a distillation of
the architectural properties that Dr. Fielding identified as being
vital to the Web's robustness and enormous scalability.</p>
<p>Since each reservation in our example will have a distinct URI,
the Reservation Details Web service can be offered using HTTP GET
and HTTP PUT. The binding would be modified as follows:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"reservationDetails_HTTP_example" id=
"reservationDetails_HTTP_example"></a><em><span>Example
5-14.</span> Reservation Details Web Service Using HTTP
Transfer</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
. . .
&lt;binding name="reservationDetailsHTTPBinding"
        type="http://www.w3.org/ns/wsdl/http"
    interface="tns:reservationDetailsInterface" &gt;

        &lt;operation ref="tns:retrieve"
            whttp:method="GET" /&gt;

        &lt;operation ref="tns:update"
            whttp:method="PUT" /&gt;

&lt;/binding&gt;
. . .
</pre></div>
</div>
<p>As with the example in <a href=
"#reservationDetails"><strong>5.3.1 The Reservation Details Web
Service</strong></a> , service and endpoint elements are not
provided because the Reservation List Web service provides the
endpoints.</p>
</div>
<div class="div3">
<h4><a name="reservationList_HTTP_GET" id=
"reservationList_HTTP_GET"></a>5.3.4 Reservation List Web Service
Using HTTP GET</h4>
<p>This section continues the REST-style example of <a href=
"#reservationDetails_HTTP"><strong>5.3.3 Reservation Details Web
Service Using HTTP Transfer</strong></a> by modifying the example
of <a href="#reservationList"><strong>5.3.2 The Reservation List
Web Service</strong></a> to use HTTP GET.</p>
<p>The SOAP version of the Reservation List Web service above
offers four different search operations. These can also be
expressed as various parameters in a URI used by HTTP GET:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example_reservationList_HTTP_GET" id=
"example_reservationList_HTTP_GET"></a><em><span>Example
5-15.</span> Reservation List Web Service Using HTTP GET</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
. . .
&lt;binding name="reservationListHTTPBinding"
        type="http://www.w3.org/ns/wsdl/http"
    interface="tns:reservationListInterface"
    whttp:methodDefault="GET"&gt;

  &lt;operation ref="tns:retrieve"
      whttp:location="" /&gt;

  &lt;operation ref="tns:retrieveByConfirmationNumber"
      whttp:location="reservationList/ConfirmationNumber/{confirmationNumber/}" /&gt;

  &lt;operation ref="tns:retrieveByCheckInDate"
      whttp:location="reservationList/CheckInDate/{checkInDate/}" /&gt;

  &lt;operation ref="tns:retrieveByCheckOutDate"
      whttp:location="reservationList/CheckOutDate/{checkOutDate/}" /&gt;
&lt;/binding&gt;
. . .
&lt;service . . . &gt;

  &lt;endpoint name="reservationListEndpoint"
    binding="tns:reservationListHTTPBinding"
    address="http://greath.example.com/2004/reservationList" /&gt;
. . .
&lt;/service&gt;
. . .
</pre></div>
</div>
<p>A retrieval by Confirmation Number URI would look like:
<code>http://greath.example.com/2004/reservationList/ConfirmationNumber/HSG635
.</code></p>
<p>Alternatively, a single query type may be provided. This query
type is a sequence of optional items. Any items in the sequence are
serialized into the URI query string. A query sequence for any of
ConfirmationNumber, checkInDate, checkOutDate would look like
this:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example_reservationList_HTTP_GET_single" id=
"example_reservationList_HTTP_GET_single"></a><em><span>Example
5-16.</span> Query Sequence Using a Single Query Type</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
&lt;element name="reservationQuery"&gt;
  &lt;annotation&gt;
    &lt;documentation&gt;
      A reservation contains the confirmation number, check-in
      and check-out dates, and a reference to a Reservation
      Details Web service.
    &lt;/documentation&gt;
  &lt;/annotation&gt;
  &lt;complexType&gt;
    &lt;sequence&gt;
      &lt;element ref="details:confirmationNumber" minOccurs="0"/&gt;
      &lt;element ref="details:checkInDate" minOccurs="0"/&gt;/&gt;
      &lt;element ref="details:checkOutDate" minOccurs="0"/&gt;/&gt;
    &lt;/sequence&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;
&lt;/element&gt;
</pre></div>
</div>
<p>The WSDL 2.0 service that offers this type serialized as a
parameter would look like this:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><a name=
"example_reservationList_HTTP_GET_single_wsdl" id=
"example_reservationList_HTTP_GET_single_wsdl"></a><em><span>Example
5-17.</span> WSDL 2.0 for Using a Single Query Type</em></p>
<div class="exampleInner">
<pre xml:space="preserve">
. . .
&lt;interface name="reservationListInterfaceWithQuery"&gt;

  &lt;operation name="retrieveByReservationQuery"
                pattern="http://www.w3.org/ns/wsdl/in-out"&gt;
    &lt;input messageLabel="In"
        element="details:ReservationQuery" /&gt;
    &lt;output messageLabel="Out"
        element="list:reservationList" /&gt;
  &lt;/operation&gt;

&lt;/interface&gt;

&lt;binding name="reservationListQueryHTTPBinding"
        type="http://www.w3.org/ns/wsdl/http"
    interface="tns:reservationListInterfaceWithQuery"
    whttp:methodDefault="GET"&gt;

  &lt;operation ref="tns:retrieveByReservationQuery"
      whttp:location="reservationList/{ReservationQuery}}" /&gt;

&lt;/binding&gt;

. . .
  &lt;endpoint name="reservationListEndpoint"
      binding="tns:reservationListHTTPBinding"
      address="http://greath.example.com/2004/reservationList" /&gt;
. . .
</pre></div>
</div>
<p>Various URIs would be:
<code>http://greath.example.com/2004/reservationList/ReservationQuery?confirmationNumber=HSG635</code>
<code>http://greath.example.com/2004/reservationList/ReservationQuery?checkInDate=06-06-05</code>
.</p>
<p>It is important to observe that using the URI serialization can
result in very flexible queries and few operations. The previous
discrete SOAP operations are collapsed into one "parameterized"
operation.</p>
</div>
</div>
<div class="div2">
<h3><a name="adv-multiple-docs-describing-same-service" id=
"adv-multiple-docs-describing-same-service"></a>5.4 Multiple
Interfaces for the Same Service</h3>
<p>Suppose a Web service wishes to expose two different interfaces:
a customer interface for its regular users, and a management
interface for its operator. A <code>wsdl:service</code> specifies
only one wsdl:interface, so to achieve the desired effect the
service provider would somehow need to indicate a relationship
between two services. How can a service provider indicate a
relationship between services? Potential strategies include:</p>
<ul>
<li>
<p><strong>Declare both interfaces in the same wsdl:description
element.</strong> Although WSDL 2.0 does not ascribe any particular
significance to the fact that two wsdl:services are declared within
the same wsdl:description, an application or toolkit could
interpret this to mean that they are related in some way.</p>
</li>
<li>
<p><strong>Declare both interfaces in the same
wsdl:targetNamespace.</strong> Again, although WSDL 2.0 does not
ascribe any particular significance to the fact that two
wsdl:services are declared within the same wsdl:targetNamespace, an
application or toolkit could interpret this to mean that they are
related in some way.</p>
</li>
<li>
<p><strong>Add an extension to WSDL 2.0</strong> that links
together all services that are related in this way. WSDL 2.0's open
content model permits extension elements from other namespaces to
appear in a WSDL 2.0 document.</p>
</li>
<li>
<p><strong>Declare them in completely separate WSDL 2.0 documents,
but use the same endpoint address for both.</strong> I.e., declare
a <code>wsdl:interface</code> and <code>wsdl:service</code> for the
customer interface in one WSDL 2.0 document, and a
<code>wsdl:interface</code> and <code>wsdl:service</code> for the
management interface in a different WSDL 2.0 document, but use the
same endpoint address for both. (By "different WSDL 2.0 document"
we mean that both documents are never included or imported into the
same WSDL 2.0 descriptions component.) Although this approach may
work in some circumstances, it means that the same endpoint address
would be used for two different purposes, which is apt to cause
confusion or ambiguity. Furthermore, it is contrary to the Web
architectural principle that different URIs should be used to
identify different Web resources. (See the Web Architecture
[<cite><a href="#webarch">Web Architecture</a></cite>] section on
<a href="http://www.w3.org/TR/webarch/#URI-collision">URI
collision</a>.)</p>
</li>
<li>
<p><strong>Use inheritance to combine the customer interface and
management interface</strong> into a single, larger wsdl:interface.
Of course, this reduces modularity and means that the management
interface becomes exposed to the customers, which is not good.</p>
</li>
</ul>
<p>Bear in mind that since the above strategies step outside of the
WSDL 2.0 language specifies (and are therefore neither endorsed nor
forbidden by the WSDL 2.0 specification) the WSDL 2.0 specification
cannot define or standardize their semantics.</p>
<p>The desire to express relationships between services is also
relevant to Web service versioning, discussed next.</p>
</div>
<div class="div2">
<h3><a name="adv-rdf-mapping" id="adv-rdf-mapping"></a>5.5 Mapping
to RDF and Semantic Web</h3>
<p>WSDL 2.0 is a language designed primarily with XML syntax. While
XML is almost universally understood, it has several issues:</p>
<ul>
<li>
<p>The ability to compose two XML documents into one depends on the
languages of those documents. WSDL 2.0 does not permit Web service
descriptions in different targetNamespaces to be merged into a
single (physical) XML document.</p>
</li>
<li>
<p>The ability to extend XML languages with other XML languages
depends on the languages again. WSDL 2.0 is extremely extensible,
but the meaning of every single extension in WSDL 2.0 must be
defined explicitly. Putting a piece of XMI (XML format for UML)
into a WSDL 2.0 document may have different meaning from putting it
into an XHTML document. Therefore XML-based extensibility has very
high cost if many languages are involved.</p>
</li>
<li>
<p>Similarly, extending another XML language with pieces of WSDL
2.0, while possible, has to be defined for all the possible
destinations. Putting a WSDL 2.0 interface element into a UDDI
registry may mean a different thing from putting that interface
element into an XHTML document.</p>
</li>
<li>
<p>Finally, the meaning of a portion of a WSDL 2.0 document is not
defined by the WSDL 2.0 specification. While an interface element
could form a single XML document, it is not a WSDL 2.0 document, so
its meaning is largely undefined.</p>
</li>
</ul>
<p>Applications that require such levels of composability (or
decomposability) are increasingly being based on RDF
[<cite><a href="#rdf">RDF</a></cite>], a graph-based knowledge
representation language, and Web Ontology Language (OWL)
[<cite><a href="#owl">OWL</a></cite>], which can be thought of as
an advanced schema language for RDF. Effectively, a WSDL 2.0
document represented in RDF can be more easily extended with
arbitrary RDF assertions and the WSDL 2.0 information can be more
easily associated with arbitrary other knowledge.</p>
<div class="div3">
<h4><a name="adv-rdf-rep-wsdl" id="adv-rdf-rep-wsdl"></a>5.5.1 RDF
Representation of WSDL 2.0</h4>
<p><em>WSDL 2.0: Mapping to RDF</em> [<cite><a href="#RDFmap">WSDL
2.0 RDF Mapping</a></cite>] describes how WSDL 2.0 constructs can
be expressed in RDF using classes of resources (described with an
ontology expressed in OWL) and assertions over individual
resources. As RDF represents knowledge using resources and
relationships between them, we need to turn WSDL 2.0 concepts into
this model. This is done as follows.</p>
<ol class="enumar">
<li>
<p>First, all components in WSDL 2.0 (like Interfaces, Operations,
Bindings, Services, Endpoints etc., including extensions) are
turned into resources identified with the appropriate URIs created
according to <a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626#wsdl-iri-references">
Appendix C IRI-References for WSDL 2.0 Components</a> of
[<cite><a href="#WSDL-PART1">WSDL 2.0 Core</a></cite>].</p>
</li>
<li>
<p>Further, things are represented as resources:</p>
<ol class="enumla">
<li>
<p>Element declarations gathered from XML Schema (or similarly,
other components from other type systems)</p>
</li>
<li>
<p>Message content models</p>
</li>
<li>
<p>Message exchange patterns (the URI identifying the MEP is the
URI of the resource)</p>
</li>
<li>
<p>Operation styles (similarly to MEPs, the URI of an operation
style is the URI of the resource)</p>
</li>
</ol>
</li>
<li>
<p>All the resources above are given the appropriate types using
rdf:type statements (an interface will belong to the class
Interface and an operation within an interface will belong to the
class InterfaceOperation, for example).</p>
</li>
<li>
<p>All relationships in WSDL 2.0 (like an Operation's belonging to
an Interface and having a given operation style) are turned into
RDF statements using appropriate properties, such as
<code>operation</code> and <code>operationStyle</code>.</p>
</li>
</ol>
</div>
</div>
<div class="div2">
<h3><a name="adv-notes-on-uris" id="adv-notes-on-uris"></a>5.6
Notes on URIs</h3>
<div class="div3">
<h4><a name="adv-namespaces-and-schema-locations" id=
"adv-namespaces-and-schema-locations"></a>5.6.1 XML Namespaces and
Schema Locations</h4>
<p>It is a common misperception to equate either the target
namespace of an XML Schema or the value of the <code>xmlns</code>
attribute in XML instances with the location of the corresponding
schema. Even though namespaces are URIs, and URIs may be locations,
and it may be possible to retrieve a schema from such a location,
this does not mean that the retrieved schema is the <em>only</em>
schema that is associated with that namespace. There can be
multiple schemas associated with a particular namespace, and it is
up to a processor of XML to determine which one to use in a
particular processing context. The WSDL 2.0 specification provides
the processing context here via the <code>import</code> mechanism,
which is based on XML Schema's term for the similar concept.</p>
</div>
<div class="div3">
<h4><a name="adv-relative-uris" id="adv-relative-uris"></a>5.6.2
Relative URIs</h4>
<p>Throughout this document there are fully qualified URIs used in
WSDL 2.0 and XSD examples. In some cases, fully qualified URIs were
used simply to illustrate the referencing concepts. However, the
use of relative URIs is allowed and warranted in many cases. For
information on processing relative URIs, see <a href=
"http://www.ietf.org/rfc/rfc3986.txt">RFC3986</a>.</p>
</div>
<div class="div3">
<h4><a name="adv-generating-uris" id=
"adv-generating-uris"></a>5.6.3 Generating Temporary URIs</h4>
<p>In general, when a WSDL 2.0 document is published for use by
others, it should only contain URIs that are globally unique. This
is usually done by allocating them under a domain name that is
controlled by the issuer. For example, the W3C allocates namespace
URIs under its base domain name, w3.org.</p>
<p>However, it is sometimes desirable to make up a temporary URI
for an entity, for use during development, but not make the URI
globally unique for all time and have it "mean" that version of the
entity (schema, WSDL 2.0 document, etc.). <em>Reserved Top Level
DNS Names</em> [<cite><a href="#RFC2606">IETF RFC 2606</a></cite>]
specifies some URI base names that are reserved for use for this
type of behavior. For example, the base URI "http://example.org/"
can be used to construct a temporary URI without any unique
association to an entity. This means that two people or programs
could choose to simultaneously use the temporary URI "
http://example.org/userSchema" for two completely different
schemas. As long as the scope of use of these URIs does not
intersect, then they would be unique enough. However, it is not
recommended that " http://example.org/" be used as a base for
stable, fixed entities.</p>
</div>
</div>
</div>
<div class="div1">
<h2><a name="References" id="References"></a>6. References</h2>
<div class="div2">
<h3><a name="Normative-References" id=
"Normative-References"></a>6.1 Normative References</h3>
<dl>
<dt class="label"><a name="RFC2119" id="RFC2119"></a>[IETF RFC
2119]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2119.txt">Key words
for use in RFCs to Indicate Requirement Levels</a></cite>, S.
Bradner, Author. Internet Engineering Task Force, March 1997.
Available at http://www.ietf.org/rfc/rfc2119.txt</dd>
<dt class="label"><a name="RFC3023" id="RFC3023"></a>[IETF RFC
3023]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc3023.txt">XML Media
Types</a></cite>, M. Murata, S. St. Laurent, D. Kohn, Authors.
Internet Engineering Task Force, January 2001. Available at
http://www.ietf.org/rfc/rfc3023.txt</dd>
<dt class="label"><a name="RFC3986" id="RFC3986"></a>[IETF RFC
3986]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc3986.txt">Uniform
Resource Identifier (URI): Generic Syntax</a></cite>, T.
Berners-Lee, R. Fielding, L. Masinter, Authors. Internet
Engineering Task Force, January 2005. Available at
http://www.ietf.org/rfc/rfc3986.txt</dd>
<dt class="label"><a name="RFC3987" id="RFC3987"></a>[IETF RFC
3987]</dt>
<dd><cite><a href=
"http://www.ietf.org/rfc/rfc3987.txt">Internationalized Resource
Identifiers (IRIs)</a></cite>, M. Duerst, M. Suignard, Authors.
Internet Engineering Task Force, January 2005. Available at
http://www.ietf.org/rfc/rfc3987.txt</dd>
<dt class="label"><a name="XML10" id="XML10"></a>[XML 1.0]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2006/REC-xml-20060816">Extensible Markup
Language (XML) 1.0 (Fourth Edition)</a></cite>, T. Bray, J. Paoli,
C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web
Consortium, 10 February 1998, revised 16 August 2006. This version
of the XML 1.0 Recommendation is
http://www.w3.org/TR/2006/REC-xml-20060816. The <a href=
"http://www.w3.org/TR/xml">latest version of XML 1.0</a> is
available at http://www.w3.org/TR/xml.</dd>
<dt class="label"><a name="XMLInfoSet" id="XMLInfoSet"></a>[XML
Information Set]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2004/REC-xml-infoset-20040204/">XML
Information Set (Second Edition)</a></cite>, J. Cowan and R. Tobin,
Editors. World Wide Web Consortium, 24 October 2001, revised 4
February 2004. This version of the XML Information Set
Recommendation is
http://www.w3.org/TR/2004/REC-xml-infoset-20040204/. The <a href=
"http://www.w3.org/TR/xml-infoset">latest version of XML
Information Set</a> is available at
http://www.w3.org/TR/xml-infoset.</dd>
<dt class="label"><a name="XMLNS" id="XMLNS"></a>[XML
Namespaces]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2006/REC-xml-names-20060816/">Namespaces in
XML 1.0 (Second Edition)</a></cite>, T. Bray, D. Hollander, A.
Layman, and R. Tobin, Editors. World Wide Web Consortium, 14
January 1999, revised 16 August 2006. This version of Namespaces in
XML 1.0 Recommendation is
http://www.w3.org/TR/2006/REC-xml-names-20060816/. The <a href=
"http://www.w3.org/TR/xml-names/">latest version of Namespaces in
XML</a> is available at http://www.w3.org/TR/xml-names.</dd>
<dt class="label"><a name="XMLSchemaP1" id="XMLSchemaP1"></a>[XML
Schema Structures]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
Part 1: Structures Second Edition</a></cite>, H. Thompson, D.
Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web
Consortium, 2 May 2001, revised 28 October 2004. This version of
the XML Schema Part 1 Recommendation is
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The <a href=
"http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema
Part 1</a> is available at http://www.w3.org/TR/xmlschema-1.</dd>
<dt class="label"><a name="XMLSchemaP2" id="XMLSchemaP2"></a>[XML
Schema Datatypes]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema
Part 2: Datatypes Second Edition</a></cite>, P. Byron and A.
Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised
28 October 2004. This version of the XML Schema Part 2
Recommendation is
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The <a href=
"http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema
Part 2</a> is available at http://www.w3.org/TR/xmlschema-2.</dd>
<dt class="label"><a name="WSDL-PART1" id="WSDL-PART1"></a>[WSDL
2.0 Core]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626">Web Services
Description Language (WSDL) Version 2.0 Part 1: Core
Language</a></cite>, R. Chinnici, J-J. Moreau, A. Ryman, S.
Weerawarana, Editors. World Wide Web Consortium, 26 June 2007. This
version of the "Web Services Description Language (WSDL) Version
2.0 Part 1: Core Language" Recommendation is available is available
at http://www.w3.org/TR/2007/REC-wsdl20-20070626. The <a href=
"http://www.w3.org/TR/wsdl20">latest version of "Web Services
Description Language (WSDL) Version 2.0 Part 1: Core Language"</a>
is available at http://www.w3.org/TR/wsdl20.</dd>
<dt class="label"><a name="WSDL-PART2" id="WSDL-PART2"></a>[WSDL
2.0 Adjuncts]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626">Web
Services Description Language (WSDL) Version 2.0 Part 2:
Adjuncts</a></cite>, R. Chinnici, H. Haas, A. Lewis, J-J. Moreau,
D. Orchard, S. Weerawarana, Editors. World Wide Web Consortium, 26
June 2007. This version of the "Web Services Description Language
(WSDL) Version 2.0 Part 2: Adjuncts" Recommendation is available at
http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626. The
<a href="http://www.w3.org/TR/wsdl20-adjuncts">latest version of
"Web Services Description Language (WSDL) Version 2.0 Part 2:
Adjuncts"</a> is available at
http://www.w3.org/TR/wsdl20-adjuncts.</dd>
<dt class="label"><a name="WSDL-SOAP11" id="WSDL-SOAP11"></a>[WSDL
2.0 SOAP 1.1 Binding]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/NOTE-wsdl20-soap11-binding-20070626">Web
Services Description Language (WSDL) Version 2.0 SOAP 1.1
Binding</a></cite>, A. Vedamuthu, Editor. World Wide Web
Consortium, 26 June 2007. This version of the "Web Services
Description Language (WSDL) Version 2.0 SOAP 1.1 Binding" Working
Group Note is available at
http://www.w3.org/TR/2007/NOTE-wsdl20-soap11-binding-20070626. The
<a href="http://www.w3.org/TR/wsdl20-soap11-binding">latest version
of "Web Services Description Language (WSDL) Version 2.0 SOAP 1.1
Binding"</a> is available at
http://www.w3.org/TR/wsdl20-soap11-binding.</dd>
<dt class="label"><a name="RDFmap" id="RDFmap"></a>[WSDL 2.0 RDF
Mapping]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/NOTE-wsdl20-rdf-20070626">Web Services
Description Language (WSDL) Version 2.0: RDF Mapping</a></cite>, J.
Kopecký, B. Parsia, Editors. World Wide Web Consortium, 26 June
2007. This version of the "Web Services Description Language (WSDL)
Version 2.0: RDF Mapping" Working Group Note is available at
http://www.w3.org/TR/2007/NOTE-wsdl20-rdf-20070626. The <a href=
"http://www.w3.org/TR/wsdl20-rdf">latest version of "Web Services
Description Language (WSDL) Version 2.0: RDF Mapping"</a> is
available at http://www.w3.org/TR/wsdl20-rdf.</dd>
<dt class="label"><a name="webarch" id="webarch"></a>[Web
Architecture]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2004/REC-webarch-20041215/">Architecture of
the World Wide Web, Volume One</a></cite>, Ian Jacobs, Norman
Walsh, Editors. W3C Recommendation, 15 December, 2004. Available at
http://www.w3.org/TR/2004/REC-webarch-20041215/ .</dd>
<dt class="label"><a name="wsarch" id="wsarch"></a>[WS
Architecture]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2004/REC-webarch-20041215/">Web Services
Architecture</a></cite>, David Booth, et al., Editors. W3C Working
Group Note, 11 February 2004. Available at
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/ .</dd>
<dt class="label"><a name="WSAGLOSS" id="WSAGLOSS"></a>[WS
Glossary]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/">Web Services
Glossary</a></cite>, Hugo Haas, Allen Brown, Editors. W3C Working
Group Note, 11 February 2004. Available at
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/ .</dd>
<dt class="label"><a name="DESCRIBEMEDIA" id=
"DESCRIBEMEDIA"></a>[Describing Media Content of Binary Data in
XML]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/xml-media-types/">Describing Media Content of
Binary Data in XML</a></cite>, Anish Karmarkar, Ümit Yalçınalp,
Editors. W3C Working Group Note 4 May 2005. Available at
http://www.w3.org/TR/xml-media-types/</dd>
</dl>
</div>
<div class="div2">
<h3><a name="Informative-References" id=
"Informative-References"></a>6.2 Informative References</h3>
<dl>
<dt class="label"><a name="RFC2606" id="RFC2606"></a>[IETF RFC
2606]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2606.txt">Reserved
Top Level DNS Names</a></cite>, D. Eastlake, A. Panitz, Authors.
Network Working Group, Internet Engineering Task Force, June 1999.
Available at http://www.ietf.org/rfc/rfc2606.txt.</dd>
<dt class="label"><a name="RFC2616" id="RFC2616"></a>[IETF RFC
2616]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext
Transfer Protocol -- HTTP/1.1</a></cite>, R. Fielding, J. Gettys,
J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee,
Authors. Internet Engineering Task Force, June 1999. Available at
http://www.ietf.org/rfc/rfc2616.txt.</dd>
<dt class="label"><a name="RFC2818" id="RFC2818"></a>[IETF RFC
2818]</dt>
<dd><cite><a href="http://www.ietf.org/rfc/rfc2818.txt">HTTP Over
TLS</a></cite>, E. Rescorla, Author. Internet Engineering Task
Force, May 2000. Available at
http://www.ietf.org/rfc/rfc2818.txt.</dd>
<dt class="label"><a name="SOAP11" id="SOAP11"></a>[SOAP 1.1]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object
Access Protocol (SOAP) 1.1</a></cite>, D. Box, D. Ehnebuske, G.
Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S. Thatte,
D. Winer, Editors. World Wide Web Consortium, 8 May 2000. This
version of the Simple Object Access Protocol 1.1 Note is
http://www.w3.org/TR/2000/NOTE-SOAP-20000508.</dd>
<dt class="label"><a name="SOAP12-PART1" id=
"SOAP12-PART1"></a>[SOAP 1.2 Part 1: Messaging Framework]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-soap12-part1-20070427/">SOAP Version
1.2 Part 1: Messaging Framework (Second Edition)</a></cite>, M.
Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen,
Editors. World Wide Web Consortium, 24 June 2003, revised 27 April
2007. This version of the "SOAP Version 1.2 Part 1: Messaging
Framework" Recommendation is
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. The <a href=
"http://www.w3.org/TR/soap12-part1/">latest version of "SOAP
Version 1.2 Part 1: Messaging Framework"</a> is available at
http://www.w3.org/TR/soap12-part1/.</dd>
<dt class="label"><a name="SOAP12-PART2" id=
"SOAP12-PART2"></a>[SOAP 1.2 Part 2: Adjuncts]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-soap12-part2-20070427/">SOAP Version
1.2 Part 2: Adjuncts</a></cite>, M. Gudgin, M. Hadley, N.
Mendelsohn, J-J. Moreau, and H. Frystyk Nielsen, Editors. World
Wide Web Consortium, 7 May 2003, revised 27 April 2007. This
version of the "SOAP Version 1.2 Part 2: Adjuncts" Recommendation
is http://www.w3.org/TR/2007/REC-soap12-part2-20070427/. The
<a href="http://www.w3.org/TR/soap12-part2/">latest version of
"SOAP Version 1.2 Part 2: Adjuncts"</a> is available at
http://www.w3.org/TR/soap12-part2/.</dd>
<dt class="label"><a name="SOAP-MTOM" id="SOAP-MTOM"></a>[SOAP
MTOM]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">SOAP Message
Transmission Optimization Mechanism</a></cite> , M. Gudgin, N.
Mendelsohn, M. Nottingham, H. Ruellan, Editors. World Wide Web
Consortium, 25 January, 2005. This version of SOAP Message
Transmission Optimization Mechanism is available at <a href=
"http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/</a>
http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/.</dd>
<dt class="label"><a name="WSDReqs" id="WSDReqs"></a>[WSD
Requirements]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028">Web Services
Description Requirements</a></cite>, J. Schlimmer, Editor. World
Wide Web Consortium, 17 October 2002. This version of the Web
Services Description Requirements document is
http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028. The <a href=
"http://www.w3.org/TR/ws-desc-reqs/">latest version of Web Services
Description Requirements</a> is available at
http://www.w3.org/TR/ws-desc-reqs.</dd>
<dt class="label"><a name="WS-A" id="WS-A"></a>[WS-Addressing]</dt>
<dd><cite><a href="http://www.w3.org/TR/ws-addr-core/">Web Services
Addressing 1.0 - Core</a></cite>, Martin Gudgin, Marc Hadley,
Editor. World Wide Web Consortium, 17 August 2005. This version of
the Web Services Addressing 1.0 - Core document is available at
http://www.w3.org/TR/ws-addr-core/. The <a href=
"http://www.w3.org/TR/ws-addr-core/">latest version of Web Services
Description Requirements</a> is available at
http://www.w3.org/TR/ws-addr-core/.</dd>
<dt class="label"><a name="XPTR" id="XPTR"></a>[XPointer
Framework]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2003/REC-xptr-framework-20030325/">XPointer
Framework</a></cite>, Paul Grosso, Eve Maler, Jonathan Marsh,
Norman Walsh, Editors. World Wide Web Consortium, 25 March 2003.
This version of the XPointer Framework Proposed Recommendation is
http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ The <a href=
"http://www.w3.org/TR/xptr-framework/">latest version of XPointer
Framework</a> is available at
http://www.w3.org/TR/xptr-framework/.</dd>
<dt class="label"><a name="TAG-whenToUseGET" id=
"TAG-whenToUseGET"></a>[W3C TAG Finding: Use of HTTP GET]</dt>
<dd><cite><a href=
"http://www.w3.org/2001/tag/doc/whenToUseGet">URIs, Addressability,
and the use of HTTP GET and POST</a></cite>, Ian Jacobs, Editor.
World Wide Web Consortium, 21 March 2004. Available at
http://www.w3.org/2001/tag/doc/whenToUseGet</dd>
<dt class="label"><a name="TAG-versioning" id=
"TAG-versioning"></a>[W3C TAG Finding: Extending and Versioning
Languages Part 1]</dt>
<dd><cite><a href=
"http://www.w3.org/2001/tag/doc/versioning">Extending and
Versioning Languages Part 1</a></cite> David Orchard, Editor. World
Wide Web Consortium, 26 March 2006. Available at
http://www.w3.org/2001/tag/doc/versioning</dd>
<dt class="label"><a name="web-extensible" id=
"web-extensible"></a>[WebArch: Extensible Languages]</dt>
<dd><cite><a href="http://www.w3.org/TR/NOTE-webarch-extlang">Web
Architecture: Extensible Languages</a></cite> , Tim Berners-Lee,
Dan Connolly, Authors. W3C Note 10 Feb 1998. Available at
http://www.w3.org/TR/NOTE-webarch-extlang</dd>
<dt class="label"><a name="xsd-versioning" id=
"xsd-versioning"></a>[XML Schema: Versioning Use-Cases]</dt>
<dd><cite><a href=
"http://www.w3.org/XML/2005/xsd-versioning-use-cases/">XML Schema
Versioning Use Cases</a></cite> , Hoylen Sue. W3C XML Schema
Working Group Draft, 31 January 2006. Available at
http://www.w3.org/XML/2005/xsd-versioning-use-cases/</dd>
<dt class="label"><a name="xsd-versioning-guide" id=
"xsd-versioning-guide"></a>[Guide to Versioning XML Languages using
XML Schema 1.1]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/xmlschema-guide2versioning">Guide to
Versioning XML Languages using XML Schema 1.1</a></cite>, David
Orchard. W3C XML Schema Working Group Draft, 28 September 2006.
Available at http://www.w3.org/TR/xmlschema-guide2versioning</dd>
<dt class="label"><a name="xsd11" id="xsd11"></a>[XML Schema
1.1]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/">XML Schema
1.1 Part 1: Structures</a></cite>, H. Thompson, C. M.
Sperberg-McQueen, Shudi (Sandy) Gao, N. Mendelsohn, David Beech,
Murray Maloney, Editors. World Wide Web Consortium, 31 August 2006.
This Working Draft of XML Schema 1.1 Part 1 is
http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/. The <a href=
"http://www.w3.org/TR/xmlschema11-1/">latest version of XML Schema
1.1 Part 1</a> is available at
http://www.w3.org/TR/xmlschema11-1/.</dd>
<dt class="label"><a name="sw-vocabulary" id=
"sw-vocabulary"></a>[SW VocabManagementNote]</dt>
<dd><cite><a href=
"http://esw.w3.org/topic/VocabManagementNote">Vocabulary
Management</a></cite> , Thomas Baker, et al. Semantic Web Best
Practices and Deployment Working Group Note, 8 Feb 2005. Available
at http://esw.w3.org/topic/VocabManagementNote</dd>
<dt class="label"><a name="relax-ng" id="relax-ng"></a>[RELAX
NG]</dt>
<dd><cite><a href=
"http://www.oasis-open.org/committees/relax-ng/spec-20011203.html">RELAX
NG Specification</a></cite>, James Clark, MURATA Makoto, Editors.
OASIS Committee Specification, 3 December 2001. Available at
http://www.oasis-open.org/committees/relax-ng/spec-20011203.html</dd>
<dt class="label"><a name="jaxrpc" id="jaxrpc"></a>[JAX RPC
1.1]</dt>
<dd><cite><a href=
"http://java.sun.com/xml/downloads/jaxrpc.html">Java(TM) API for
XML-based Remote Procedure Call (JAX-RPC) Specification, version
1.1</a></cite>, Roberto Chinnici,et al. 14 October, 2003. Available
at http://java.sun.com/xml/downloads/jaxrpc.html</dd>
<dt class="label"><a name="rest" id="rest"></a>[REST]</dt>
<dd><cite><a href=
"http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm">
Representational State Transfer (REST)</a></cite>, Roy Thomas
Fielding, Author. 2000. Available at
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm</dd>
<dt class="label"><a name="rdf" id="rdf"></a>[RDF]</dt>
<dd><cite><a href="http://www.w3.org/TR/rdf-concepts/">Resource
Description Framework (RDF): Concepts and Abstract
Syntax</a></cite>, Graham Klyne, Jeremy J. Carroll, Editors. W3C
Recommendation, 10 February 2004. Available at
http://www.w3.org/TR/rdf-concepts/</dd>
<dt class="label"><a name="owl" id="owl"></a>[OWL]</dt>
<dd><cite><a href="http://www.w3.org/TR/owl-ref/">OWL Web Ontology
Language Reference</a></cite>, Mike Dean,Guus Schreiber, Editors.
W3C Recommendation 10 February 2004 . Available at
http://www.w3.org/TR/owl-ref/</dd>
<dt class="label"><a name="altschemalangs" id=
"altschemalangs"></a>[Alternative Schema Languages Support]</dt>
<dd><cite><a href=
"http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/altschemalangs.html?content-type=text/html;%20charset=utf-8&amp;rev=1.3">
Discussion of Alternative Schema Languages and Type System Support
in WSDL</a></cite>, A. Lewis, B. Parsia, Editors.</dd>
</dl>
</div>
</div>
</div>
<div class="back div1">
<h2><a name="acknowledgments" id="acknowledgments"></a>A.
Acknowledgements (Non-Normative)</h2>
<p>This document is the work of the <a href=
"http://www.w3.org/2002/ws/desc/">W3C Web Service Description
Working Group</a>.</p>
<p>Members of the Working Group are (at the time of writing, and by
alphabetical order): Charlton Barreto (Adobe Systems, Inc), Allen
Brookes (Rogue Wave Softwave), Dave Chappell (Sonic Software),
Helen Chen (Agfa-Gevaert N. V.), Roberto Chinnici (Sun
Microsystems), Kendall Clark (University of Maryland), Glen Daniels
(Sonic Software), Paul Downey (British Telecommunications), Youenn
Fablet (Canon), Ram Jeyaraman (Microsoft), Tom Jordahl (Adobe
Systems), Anish Karmarkar (Oracle Corporation), Jacek Kopecky (DERI
Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria),
Amelia Lewis (TIBCO Software, Inc.), Philippe Le Hegaret (W3C),
Michael Liddy (Education.au Ltd.), Kevin Canyang Liu (SAP AG),
Jonathan Marsh (WSO2), Monica Martin (Sun Microsystems), Josephine
Micallef (SAIC - Telcordia Technologies), Jeff Mischkinsky (Oracle
Corporation), Dale Moberg (Cyclone Commerce), Jean-Jacques Moreau
(Canon), David Orchard (BEA Systems, Inc.), Gilbert Pilz (BEA
Systems, Inc.), Tony Rogers (Computer Associates), Arthur Ryman
(IBM), Adi Sakala (IONA Technologies), Michael Shepherd (Xerox),
Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2),
Ümit Yalçınalp (SAP AG), Peter Zehler (Xerox).</p>
<p>Previous members were: Eran Chinthaka (WSO2), Mark Nottingham
(BEA Systems, Inc.), Hugo Haas (W3C), Vivek Pandey (Sun
Microsystems), Bijan Parsia (University of Maryland), Lily Liu
(webMethods, Inc.), Don Wright (Lexmark), Joyce Yang (Oracle
Corporation), Daniel Schutzer (Citigroup), Dave Solo (Citigroup),
Stefano Pogliani (Sun Microsystems), William Stumbo (Xerox),
Stephen White (SeeBeyond), Barbara Zengler (DaimlerChrysler
Research and Technology), Tim Finin (University of Maryland),
Laurent De Teneuille (L'Echangeur), Johan Pauhlsson (L'Echangeur),
Mark Jones (AT&amp;T), Steve Lind (AT&amp;T), Sandra Swearingen
(U.S. Department of Defense, U.S. Air Force), Philippe Le Hégaret
(W3C), Jim Hendler (University of Maryland), Dietmar Gaertner
(Software AG), Michael Champion (Software AG), Don Mullen (TIBCO
Software, Inc.), Steve Graham (Global Grid Forum), Steve Tuecke
(Global Grid Forum), Michael Mahan (Nokia), Bryan Thompson (Hicks
&amp; Associates), Ingo Melzer (DaimlerChrysler Research and
Technology), Sandeep Kumar (Cisco Systems), Alan Davies
(SeeBeyond), Jacek Kopecky (Systinet), Mike Ballantyne (Electronic
Data Systems), Mike Davoren (W. W. Grainger), Dan Kulp (IONA
Technologies), Mike McHugh (W. W. Grainger), Michael Mealling
(Verisign), Waqar Sadiq (Electronic Data Systems), Yaron Goland
(BEA Systems, Inc.), Ümit Yalçınalp (Oracle Corporation), Peter
Madziak (Agfa-Gevaert N. V.), Jeffrey Schlimmer (Microsoft
Corporation), Hao He (The Thomson Corporation), Erik Ackerman
(Lexmark), Jerry Thrasher (Lexmark), Prasad Yendluri (webMethods,
Inc.), William Vambenepe (Hewlett-Packard Company), David Booth
(W3C), Sanjiva Weerawarana (IBM), Asir Vedamuthu (webMethods,
Inc.), Igor Sedukhin (Computer Associates), Martin Gudgin
(Microsoft Corporation), Rebecca Bergersen (IONA Technologies), Ugo
Corda (SeeBeyond).</p>
<p>The people who have contributed to <a href=
"http://lists.w3.org/Archives/Public/www-ws-desc/">discussions on
www-ws-desc@w3.org</a> are also gratefully acknowledged.</p>
</div>
</body>
</html>