Je ne comprends pas la différence qu'il existe entre une bibliothèque de
classe et un web service.
Au final on a une dll pareil, on peut interroger ce que l'on veut et faire
un return de ce que l'on veut... ça communique parail par entrée/sortie ?!
On interroge de la même manière dans les pages aspx (dim toto as new
monsuperobjet).
Je sens une subtilité mais je m'emmele les crayons entre dll, classe, asmx,
wdsl, fichier.vb
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Simon Mourier
Pour parler à un web service, on n'a besoin que d'une pile TCP/IP, de savoir faire du HTTP, et du XML. C'est tout. Ce qui fait que quelle que soit mon système d'exploitation, il y a 99% de chance que je sois capable de l'utiliser. La première force d'un web service c'est donc la simplicité, et l'universalité (l'interopérabilité).
Ensuite, on trouve d'autres choses non obligatoires comme la description de ce web service (WSDL), ou des annuaires de web services (UDDI).
Enfin, les produits tels que visual studio ou le .NET framework (ou similaires dans d'autres technologies, sur d'autres plateformes) proposent des outils pour aider à la création ou à la consommation, mais ce ne sont que des outils. On trouve essentiellement deux types:
1) les outils d'aide à l'écriture de web service (le fameux attribut [WebMethod] du framework .NET), ou la classe de base WebService. 2) les outils d'aide à la création de consommateurs de web services (les fameux WSDL.EXE du framework .NET ou le "Add Web Reference" de Visual Studio.NET qui génèrent des classes proxy de consommation de ces web services)
Simon.
"TOny" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
Je ne comprends pas la différence qu'il existe entre une bibliothèque de classe et un web service. Au final on a une dll pareil, on peut interroger ce que l'on veut et faire un return de ce que l'on veut... ça communique parail par entrée/sortie ?! On interroge de la même manière dans les pages aspx (dim toto as new monsuperobjet).
Je sens une subtilité mais je m'emmele les crayons entre dll, classe, asmx, wdsl, fichier.vb
Merci de m'éclairer...
Pour parler à un web service, on n'a besoin que d'une pile TCP/IP, de savoir
faire du HTTP, et du XML. C'est tout. Ce qui fait que quelle que soit mon
système d'exploitation, il y a 99% de chance que je sois capable de
l'utiliser. La première force d'un web service c'est donc la simplicité, et
l'universalité (l'interopérabilité).
Ensuite, on trouve d'autres choses non obligatoires comme la description de
ce web service (WSDL), ou des annuaires de web services (UDDI).
Enfin, les produits tels que visual studio ou le .NET framework (ou
similaires dans d'autres technologies, sur d'autres plateformes) proposent
des outils pour aider à la création ou à la consommation, mais ce ne sont
que des outils. On trouve essentiellement deux types:
1) les outils d'aide à l'écriture de web service (le fameux attribut
[WebMethod] du framework .NET), ou la classe de base WebService.
2) les outils d'aide à la création de consommateurs de web services (les
fameux WSDL.EXE du framework .NET ou le "Add Web Reference" de Visual
Studio.NET qui génèrent des classes proxy de consommation de ces web
services)
Simon.
"TOny" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
uHKaQaROFHA.1528@TK2MSFTNGP09.phx.gbl...
Je ne comprends pas la différence qu'il existe entre une bibliothèque de
classe et un web service.
Au final on a une dll pareil, on peut interroger ce que l'on veut et faire
un return de ce que l'on veut... ça communique parail par entrée/sortie ?!
On interroge de la même manière dans les pages aspx (dim toto as new
monsuperobjet).
Je sens une subtilité mais je m'emmele les crayons entre dll, classe,
asmx, wdsl, fichier.vb
Pour parler à un web service, on n'a besoin que d'une pile TCP/IP, de savoir faire du HTTP, et du XML. C'est tout. Ce qui fait que quelle que soit mon système d'exploitation, il y a 99% de chance que je sois capable de l'utiliser. La première force d'un web service c'est donc la simplicité, et l'universalité (l'interopérabilité).
Ensuite, on trouve d'autres choses non obligatoires comme la description de ce web service (WSDL), ou des annuaires de web services (UDDI).
Enfin, les produits tels que visual studio ou le .NET framework (ou similaires dans d'autres technologies, sur d'autres plateformes) proposent des outils pour aider à la création ou à la consommation, mais ce ne sont que des outils. On trouve essentiellement deux types:
1) les outils d'aide à l'écriture de web service (le fameux attribut [WebMethod] du framework .NET), ou la classe de base WebService. 2) les outils d'aide à la création de consommateurs de web services (les fameux WSDL.EXE du framework .NET ou le "Add Web Reference" de Visual Studio.NET qui génèrent des classes proxy de consommation de ces web services)
Simon.
"TOny" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
Je ne comprends pas la différence qu'il existe entre une bibliothèque de classe et un web service. Au final on a une dll pareil, on peut interroger ce que l'on veut et faire un return de ce que l'on veut... ça communique parail par entrée/sortie ?! On interroge de la même manière dans les pages aspx (dim toto as new monsuperobjet).
Je sens une subtilité mais je m'emmele les crayons entre dll, classe, asmx, wdsl, fichier.vb
Merci de m'éclairer...
Patrice
Oui, mais cette classe est un "proxy" qui va transmettre les paramètres à un service se trouvant sur un autre serveur. C'est sur ce serveur que le code réel qui implante le service va être exécutée et les résultats vont être récupérés en retour. Toute cette plomberie est effectivement transparente...
Patrice
--
"TOny" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
Je ne comprends pas la différence qu'il existe entre une bibliothèque de classe et un web service. Au final on a une dll pareil, on peut interroger ce que l'on veut et faire un return de ce que l'on veut... ça communique parail par entrée/sortie ?! On interroge de la même manière dans les pages aspx (dim toto as new monsuperobjet).
Je sens une subtilité mais je m'emmele les crayons entre dll, classe,
asmx,
wdsl, fichier.vb
Merci de m'éclairer...
Oui, mais cette classe est un "proxy" qui va transmettre les paramètres à un
service se trouvant sur un autre serveur. C'est sur ce serveur que le code
réel qui implante le service va être exécutée et les résultats vont être
récupérés en retour. Toute cette plomberie est effectivement transparente...
Patrice
--
"TOny" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de
news:uHKaQaROFHA.1528@TK2MSFTNGP09.phx.gbl...
Je ne comprends pas la différence qu'il existe entre une bibliothèque de
classe et un web service.
Au final on a une dll pareil, on peut interroger ce que l'on veut et faire
un return de ce que l'on veut... ça communique parail par entrée/sortie ?!
On interroge de la même manière dans les pages aspx (dim toto as new
monsuperobjet).
Je sens une subtilité mais je m'emmele les crayons entre dll, classe,
Oui, mais cette classe est un "proxy" qui va transmettre les paramètres à un service se trouvant sur un autre serveur. C'est sur ce serveur que le code réel qui implante le service va être exécutée et les résultats vont être récupérés en retour. Toute cette plomberie est effectivement transparente...
Patrice
--
"TOny" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
Je ne comprends pas la différence qu'il existe entre une bibliothèque de classe et un web service. Au final on a une dll pareil, on peut interroger ce que l'on veut et faire un return de ce que l'on veut... ça communique parail par entrée/sortie ?! On interroge de la même manière dans les pages aspx (dim toto as new monsuperobjet).
Je sens une subtilité mais je m'emmele les crayons entre dll, classe,
