Hola Diego La verdad es que hay mucha tela para cortar sobre el tema, el fundamental es escalar, crecimiento, pasa por ahi. Los 7 segundos de espera no dicen nada, que recursos implican? si me voy a a un rdbms y ejecuto uan consulta asincrónica tambien el iis se queda haciendo la plancha.. y a quien joroba?... El tema es conocer el contexto, simplemente... Sin conocerlo la primera respuesta es cola de mensajes, proceso externo y ser feliz...
De todas formas y en pro de la simpleza, callback function, llamada asincronica, que el proxy decida como lo resuelve, entonces tu cliente siempre es asincronico, el proxy internamente resuelve la invocación al servicio, sea en forma asincronica o con dos llamadas, pasa a ser transparente. Eso te permite cambiar la implementación en el server con cierta libertad, probas con llamadas asincronicas, ahi el proxy solo es un pasa manos.., si no alcanza, implementas la cola y las dos llamadas, el proxy sigue exponiendo la respuesta en forma asincronica. Aumentar la cantidad de thread no siempre es una buena solución... Saludos Daniel Calvin El día 4/12/07, Diego Jancic <[EMAIL PROTECTED]> escribió: > > Bue… pensandolo de nuevo puede ser, de todas formas no me gusta hacer > cosas muy largas dentro de IIS.. creo que con lo que propone OZ se puede > escalar mas (cambiando el método sin impacto en los clientes) > > > > Salu2 de nuevo > > > > *From:* puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] *On Behalf Of *Diego > Jancic > *Sent:* Martes, 04 de Diciembre de 2007 06:06 p.m. > *To:* puntonet@mug.org.ar > *Subject:* [puntonet] Web service asincronico ? > > > > Hola a todos los que apoyan por la solución de Oscar J > > > > Cual es la diferencia entre hacer eso (lo que dice Oscar), y: > > - Dejar el WS como esta > > - Configurar IIS para que utilice mas threads > > - Decirle a los programadores que lo hagan de forma asincrónica > > > > Lo que veo es que en todos los casos los threads son dependientes de IIS > (supongamos que no hacemos una aplicación aparte, fuera de IIS que procese), > ergo no veo diferencias en performance… > > > > Ahora, las ventajas de lo que propone OZ, son que permite al cliente > desconectarse y mucho tiempo despues ver el resultado… ahí puede ser mejor… > > Pero mejor mantenerlo simple si no se piensa hacer eso, no? > > > > Saludos > > > > > > *From:* puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] *On Behalf Of *Pata > del Santo > *Sent:* Martes, 04 de Diciembre de 2007 05:51 p.m. > *To:* puntonet@mug.org.ar > *Subject:* [puntonet] Web service asincronico ? > > > > La solución de Oscar Zarate me parece la mejor. > > Un método IniciarTarea devuelve un identificador > > Luego con ese identificador voy preguntando si hay respuesta. > > > > locata=WS.IniciarTarea() > > rpta="" > > While rpta="" > > wait(5sec) > > rpta=WS.GimmeMore(locata) > > end While > > > ------------------------------ > > *De:* puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] *En nombre de *Marcelo > P > *Enviado el:* martes, 04 de diciembre de 2007 20:49 > *Para:* puntonet@mug.org.ar > *Asunto:* [puntonet] Web service asincronico ? > > Bueno,ante todo gracias por las respuestas. > Les comento un poco mas > Las respuestas que debe dar el WS no pueden demorar mas de 5 o 7 segundo. > El tema de querer asincronismo en esto es que, a mi me pueden llegar 100 > pedidos concurrentes y no creo que el IIS corriendo asp.net pueda trabajar > con tantos hilos a la vez asi como si nada, por eso es que yo quiro un > asincronismo, ya que pienso que eso es la solución, per la verdad no lo se. > Como les dije antes, la duda mia con el asincronismo, es que si yo llamo a > un proceso A de un web service, que ejecute algoi asincronicamente, cuanlo > lo llame, me va a devolver el control al flujo del WS, por ende va a > terminar y se va a ir de nuevo al cliente, sin que todavía este la > respuesta, por ende nunca se que hay una respuesta. > Espero haber sido claro, sino avisen y lo trato de expolicar mejor. > Saludos a todos > > *Carlos Peix <[EMAIL PROTECTED]>* escribió: > > Hola Diego, > > > > La diferencia entre un WS que quede procesando y el cliente maneje el > pedido asincronico y lo que propone Oscar es "Escalabilidad". IIS y > ASP.NET <http://asp.net/> estan preparados para atender muchas peticiones > pero con la condicion de que sean de ejecucion breve, muy breve. > ASP.NET<http://asp.net/>muere tempranamente si te demoras en responder la > solicitud, incluso es > sorprendente que con unos pocos clientes puedas tirarlo por el piso. Esto no > es un error de diseño en ASP.NET <http://asp.net/>, mas bien es porque los > diseñadores asumen algunos puntos de partida, uno de ellos es que el request > debe ser resuelto lo mas rapido posible. > > > > El tema que plantea Marcelo tiene dos salidas, si el tiene requests > que impliquen no tiene mas de 10 o 15 requests concurrentes (por ejemplo, si > el request tarda 1 segundo y tiene 100 clientes que se comunican cada 10 > segundos, tiene un promedio de 10 clientes concurrentes), entonces puede > intentar ver si funciona con la solucion simple (sincronico o blocking del > lado del server y asincronico del lado del cliente). Si, en cambio, necesita > mas capacidad, probablemente necesite algo como lo que propone Oscar. > > > > La solucion que vos mencionas se acerca a la que propuso nuestro amigo > rapado (Oscar) pero adolece de algunos riesgos para mi gusto: no me gusta > mucho hostear worker threads en el proceso de ASP.NET <http://asp.net/>, > la escalabilidad es limitada tambien (no por el limite de threads de > ASP.NET <http://asp.net/> sino por la capacidad de proceso del server). > Siembre es bueno que un web server tenga mucho procesador disponible. > > > > La solucion basada en MQ para el request y uno o mas procesadores en > paralelo es buena. Queda resolver la vuelta de la respuesta. Algunos > utilizar MQ tambien para la vuelta pero a mi no me gusta, prefiero volver > por una base de datos SQLServer para tomar el mensaje por ID en lugar de > escanear toda la cola de vuelta para buscar el mensaje (hasta donde se, MQ > no tiene una operacion eficiente para tomar un mensaje por ID). Igual, esto > seria importante solo en casos de muy alto caudal. > > > > Abrazo > > > > Carlos Peix > > > > ------------------------------ > > *From:* puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] *On Behalf Of *Diego > Jancic > *Sent:* Lunes, 03 de Diciembre de 2007 08:16 p.m. > *To:* puntonet@mug.org.ar > *Subject:* [puntonet] Web service asincronico ? > > Hola Oscar, > > Pero entre enseñarle al programador a manejar ese WS con todos esos > métodos y enseñarle a hacer la llamada asincrónica (si es que no la sabe), > no es mas fácil la 2da? > > Yo justo ahora estoy haciendo algo como lo que decis, envio pedidos (via > MSMQ) y hay N threads (prefijados por configuración) que procesan todas las > tareas… pero eso es por motivos muy particulares y (si esta todo dentro de > IIS) la carga no cambia en nada… Si usas un WS, o una pagina web IIS ya te > da la funcionalidad de tener multiples threads, una cola de mensajes en > espera, etc… > > No es que quiera parecer muy negativo, pero me no lo veo eh.. J > > Salu2! > > *From:* puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] *On Behalf Of *Oscar > Zárate > *Sent:* Lunes, 03 de Diciembre de 2007 07:28 p.m. > *To:* puntonet@mug.org.ar > *Subject:* [puntonet] Web service asincronico ? > > Agrego algo mas. > > El metodo IniciarTarea podría estar escribiendo los parametros de la > consulta en una Queue y del otro lado de la Queue podría haber N servidores > leyendo la Queue y tomando el requerimiento de la consulta (haciendo la > consulta y escribiendo en la table de resultados). > > Me gusta la idea ... me parece que me fui de mambo, pero me gusta. > > SaludOZ, > > PS: No creo ser muy original con esto, ya debe estar implementado mil > veces y seguro seguro seguro ... hay un patron con nombre para resolver > esto. > > > > On 12/4/07, *Oscar Zárate* <[EMAIL PROTECTED]> wrote: > > Yo creo que la idea sería escribir algo que responda "inmediatamente" o > responda ... "preguntame luego con este ticket. > > No se cual es el negocio, pero me imagino algo que tenga mucho tiempo de > procesamiento ... entonces el web service tiene un metodo iniciar tarea (no > el proxy, el web service) este metodo inmediatamente retorna un ticket y > dispara un proceso y cuando finaliza el proceso guarda el resultado completo > en una tabla con ID igual al numero de ticket. Luego, otro metodo que recibe > el ticket y devuelve "resultado" o "preguntame luego". Este segundo metodo, > busca en la tabla si existe algun resultado para ese ticket, si existe > retorna el resultado, sino retorna "preguntame luego". > > Incluso la respuesta del proceso deberia ser formateada para que el metodo > que devuelve sea lo mas rapido posible (solo lee y retorna, no pierde tiempo > en ningun formateo). > > De este modo, haces un "servicio" (sea web o no) que es "asincronico". > Incluso en el caso de una consulta MUY RAPIDA, la consulta completa consta > igual de una llamada a dos metodos. > > Espero haber sido claro, creo que de ese modo solucionas el problema. > > > SaludOZ, > > > On 12/4/07, *Diego Jancic* <[EMAIL PROTECTED]> wrote: > > Hola, > Lo que no vas a poder hacer es que sea asincrónico desde el punto de vista > del cliente. El cliente (desarrollado por cualquier otra persona) se > conecta, recibe una respuesta y ya esta, no podes hacer nada mas. > Lo que podrías hacer es trabajar dentro del web service para que no > funcione > dentro de un thread de IIS, y asi sobrecargas menos al IIS. > > Cuando decis "o que se comporte de alguna manera de atender muchas > peticiones", no se bien a que te referis. Los WS están preparados para > recibir muchas peticiones, y si al usuario final le molesta que tarde > tanto > (imaginemos que realiza un proceso largo, pero no se está sobre cargando > el > servidor del WS), es trabajo del que arma el cliente hacer que le aparezca > un hermoso "loading..." > > Posiblemente la solución sea escribir un help para enseñarle a los otros > desarrolladores a hacer las cosas asincrónicas :) > > Saludos! > > > -----Original Message----- > From: puntonet@mug.org.ar [mailto: [EMAIL PROTECTED] On Behalf Of > Leonardo > Micheloni > Sent: Lunes, 03 de Diciembre de 2007 05:55 p.m. > To: puntonet@mug.org.ar > Subject: [puntonet] Web service asincronico ? > > Entonces no te puedo ayudar, no tengo idea > > On Dec 3, 2007 3:15 PM, Marcelo P < [EMAIL PROTECTED]> wrote: > > Gracias por la respuesta > > El tema es que yo tengo que desarrollar un web service para que sea > > consumido por cualquiera, yo no programo ni armo el proxy. Lo que tengo > que > > hacer es que el web service sea asyncronico o que se comporte de alguna > > manera de atender muchas peticiones. > > Saludos > > > > > > __________ Información de NOD32, revisión 2699 (20071203) __________ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com > > > ------------------------------ > > > Compartí video en la ventana de tus mensajes y también tus fotos de > Flickr. > Usá el Nuevo Yahoo! Messenger versión Beta. > Visitá http://ar.beta.messenger.yahoo.com/ > -- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional
