2014-04-17 23 views
7

Odziedziczyłem kilka usług internetowych, które są plikami WSDL generowanymi przez ColdFusion 9. Domyślną wartością CF9 jest kodowanie RPC, więc to właśnie one. Niedawno jednak zauważyłem, że nowsze wersje platformy .NET (a może nowsze wersje Visual Studio) nie lubią kodowanych za pomocą RPC WSDL. Podczas testowania (w języku C#) zweryfikowałem, że VS 2013 prawidłowo zużywał usługę tylko wtedy, gdy był w stylu literałowym.Jakie są konsekwencje zmiany usługi WWW WSDL generowanej przez ColdFusion z kodowania RPC do dokumentu dosłownego?

Jestem oczywiście otwarty na zmianę stylu, aby był bardziej uniwersalny, ale ten serwis internetowy jest od pewnego czasu na wolności (i jest używany przez pewną liczbę osób, jestem pewien), więc chcę mieć pewność, jakie mogą być reperkusje. Zastanawiam się również, czy można uzyskać ColdFusion, aby wygenerować dwa różne WSDL (lub zezwolić na ustawienie kodowania w locie?). Zasadniczo byłbym wdzięczny za wszelkie porady dotyczące najlepszego sposobu, aby to było zgodne (przy zachowaniu zgodności wstecznej). Dzięki.

+0

Czy znasz już jakąkolwiek dokumentację na ten temat? http://help.adobe.com/pl/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec22c24-78a6.html – fyroc

+1

O ile nie brakuje mi czegoś z tej dokumentacji (którą przeczytałem, och, osiem razy), chodzi o to, jak wygenerować WSDL, co nie jest moim pytaniem. Moje pytanie dotyczy zmiany stylu istniejącego WSDL (i jego reperkusji). –

+0

Po prostu pytałem i dawałem ci start, ponieważ nie było jeszcze odpowiedzi. Nie miał na celu udzielenia odpowiedzi, a ja bym ją opublikował jako odpowiedź. Przepraszam za zamieszanie. – fyroc

Odpowiedz

0

Jeśli masz problem z drugim adresem URL dla usługi internetowej w stylu literałowym, możesz po prostu rozszerzyć istniejący CFC. Twoja nowa CFC będzie miała te same funkcje i logikę głównej usługi internetowej. Uniemożliwiłoby to także zachowanie Nie ma żadnego dodatkowego kodu do utrzymania. Jedyną niewiadomą dla mnie jest to, czy spowoduje to znaczące dodatkowe obciążenie.

<cfcomponent extends="yourExistingCFC" style="document" output="false"></cfcomponent> 

Próbowałem ustawić typ dokumentu na literał dokumentu na jednym z moich testowych serwisów internetowych. SoapUI nie był w stanie sparsować literałowego dokumentu WSDL po zmianie, ale program Visual Studio mógł. Z tego powodu wahałbym się nad zmianą stylu dokumentu istniejącego CFC, ponieważ nie można powiedzieć, jak wszystkie środowiska klienckie poradzą sobie ze zmianą.

+0

Ah, sprytnie. Spróbuję tego. I dziękuję za testowanie - problem SoapUI jest właśnie z tego powodu, że wahałem się po prostu zmienić typ. –

+0

Zrobiłem to, co sugerowałeś, i wydaje się, że wygenerowałeś prawidłowy dokumentalny plik WSDL, który jest poprawnie przetwarzany przez program Visual Studio. Niestety, w rzeczywistości jest to zgłoszenie błędu "org.xml.sax.SAXParseException: Przedwczesny koniec pliku". Przetestowałem i otrzymałem ten sam błąd zarówno w C#, jak i ColdFusion. Jeśli jednak zmienię oryginalny komponent na styl literowo-dokumentowy i skopiuję wynikowy plik WSDL do pliku statycznego, a następnie zaktualizuję komponent rozszerzony tak, aby wskazywał na ten plik statyczny (z atrybutem 'wsdlfile') zamiast automatycznego generowania, Prace. Jakieś pomysły, co się dzieje? –

+0

W przypadku statycznego pliku WSDL powiązanie nadal wskazuje istniejący plik usługi WWW. Dopóki wygenerowane mydło wysyłane na serwer i z serwera wygląda tak samo, nie ma znaczenia, skąd pochodzi WSDL. Nie mogłem w pełni przetestować mojej sugestii, zanim zasugerowałem. Nie jestem pewien, dlaczego prośby o rozszerzoną usługę zawiodłyby. – Twillen