Info al día.

Migrando de Visual Basic 6 a Visual Basic .NET

2005-11-18T15:37:02+00:00

En esta serie de articulos veremos los cambios mas importantes que se han aplicado dentro de este lenguaje.

TIPOS DE DATOS "VARIANT"

En Visual Basic 6.0, Variant es un tipo especial de datos "universal" que puede contener cualquier clase de datos excepto cadenas de longitud fija. La variable Object se utiliza como señalador a un objeto. Variant es el tipo de datos predeterminado.

En Visual Basic .NET, el tiempo de ejecución en lenguaje común (CLR) utiliza la variable Object para el tipo de datos universal. Visual Basic.NET podría haber seguido utilizando Variant como este tipo de datos, pero se decidió adoptar la convención de nomenclatura de CLR para evitar confusiones en el desarrollo entre distintos lenguajes. El sistema de tipos se simplifica al disponer de un único tipo de datos universal. El tipo de datos predeterminado es Object.

VB 6
Dim x As Variant

VB .NET
Dim x as Object

VARIABLES "INTEGER" Y "LONG"

En Visual Basic 6, las variables Long se almacenan como números de 32 bits con signo y las variables Integer como números de 16 bits.

En Visual Basic .NET, las variables Long se almacenan como números de 64 bits con signo, las variables Integer como números de 32 bits y las variables Short como números de 16 bits.

VB 6
Dim x as Integer
Dim y as Long

VB .NET
Dim x as Short
Dim y as Integer

TIPO DE DATOS "CURRENCY"

En Visual Basic 6, las variables Currency se almacenan como números de 64 bits en un formato de enteros, con una escala de 10.000 para ofrecer un número de punto fijo con 15 dígitos a la izquierda del punto decimal y 4 dígitos a la derecha. Esta representación ofrece un intervalo de -922,337,203,685,477.5808 a 922,337,203,685,477.5807

En Visual Basic .NET, el tipo de datos Currency no proporciona suficiente precisión para evitar errores de redondeo, por lo que Decimal se creó como su propio tipo de datos.

VB 6
Dim x as Currency

VB .NET
Dim x as Decimal

VARIABLE "DATE"

En Visual Basic 6, la variable Date se almacena internamente en un formato Double y se puede manipular asimismo como Double.Las variables Date se almacenan como números de puntos flotantes IEEE de 64 bits que representan fechas que abarcan desde el 1 de enero de 100 al 31 de diciembre de 9999 y horas desde las 0:00:00 hasta las 23:59:59. Cualquier valor de datos literal reconocible se puede asignar a las variables Date.Cuando otros tipos numéricos se convierten a Date, los valores que se muestran a la izquierda del decimal representan información sobre la fecha, mientras que los valores que aparecen a la derecha representan la hora. Medianoche es 0 y mediodía 0.5. Los números enteros negativos representan fechas anteriores al 30 de diciembre de 1899.

En Visual Basic .NET, las variables Date se almacenan internamente como enteros de 64 bits, de modo que no se pueden manipular directamente como Double. .NET Framework proporciona las funciones ToOADate y FromOADate para la conversión entre Double y Date. La representación de fechas como enteros simplifica y agiliza la manipulación de fechas.

VB 6
Dim dbl As Double
Dim dat As Date
Dbl = dat

VB .NET
Dim dbl As Double
Dim dat As Date
Dbl = dat.ToOADate

Lo dejamos aca...continuamos la proxima semana...Saludos.

Serialización de objetos en .NET (2º Parte)

2005-11-11T15:06:41+00:00

En esta serie de articulos, veremos en profundidad la serializacion de objetos en ambientes .NET

Serialización selectiva
Normalmente una clase contiene campos que no deberían serializarse. Por ejemplo, imagine que una clase almacena un Id. de subproceso en una variable miembro. Al deserializar la clase, puede que no se ejecute el subproceso almacenado para el Id. cuando la clase se serializó; por consiguiente, no tiene sentido serializar este valor. Para evitar que las variables miembro se serialicen, deben marcarse con el atributo NonSerialized:

[Serializable]
public class MyObject
{
public int n1;
[NonSerialized] public int n2;
public String str;
}

Serialización personalizada
Se puede personalizar el proceso de serialización implementando la interfaz ISerializable en un objeto. Esto resulta especialmente útil en los casos en los que el valor de una variable miembro no es válido tras la deserialización, pero es necesario proporcionar la variable con un valor con el fin de reconstruir el estado completo del objeto. La implementación de ISerializable supone implementar el método GetObjectData y un constructor especial que será utilizado al deserializar el objeto. En el siguiente ejemplo de código se muestra cómo implementar ISerializable en la clase MyObject desde una sección anterior.

[Serializable]
public class MyObject : ISerializable
{
public int n1;
public int n2;
public String str;

public MyObject()
{
}

protected MyObject(SerializationInfo info, StreamingContext context)
{
n1 = info.GetInt32("i");
n2 = info.GetInt32("j");
str = info.GetString("k");
}

public virtual void GetObjectData(SerializationInfo info,
StreamingContext context)
{
info.AddValue("i", n1);
info.AddValue("j", n2);
info.AddValue("k", str);
}
}
Al llamar a GetObjectData durante la serialización, deberá llenar el objeto SerializationInfo proporcionado con la llamada al método. Para ello, simplemente agregue las variables que se van a serializar como pares de nombres/valores. Se puede utilizar como nombre cualquier texto. Ahora tiene la libertad de decidir qué variables miembro se agregan a SerializationInfo, siempre que se serialicen datos suficientes para recuperar el objeto durante la deserialización. Las clases derivadas deben llamar al método GetObjectData en el objeto base si éste implementa ISerializable.

Es importante hacer hincapié en la necesidad de implementar ambos GetObjectData, así como el constructor especial cuando se agrega ISerializable a una clase. El compilador le advertirá si falta GetObjectData, pero dado que es imposible forzar la implementación de un constructor, no recibirá advertencias si el constructor está ausente y se enviará una excepción cuando intente deserializar la clase sin el constructor. El diseño actual se vió favorecido antes del método SetObjectData para solucionar posibles problemas de seguridad y control de versiones. Por ejemplo, un método SetObjectData debe ser público si está definido como parte de una interfaz, por tanto los usuarios deben escribir código para evitar que el método SetObjectData sea llamado varias veces. Es fácil imaginar los problemas que puede ocasionar una aplicación dañina que llama al método SetObjectData en un objeto en proceso de ejecutar una operación.

Durante la deserialización, se pasa el objeto SerializationInfo a una clase mediante el constructor proporcionado para dicho fin. Al deserializar el objeto, se ignoran todas las restricciones de visibilidad en el constructor, de forma que se puede marcar la clase como pública, protegida, interna o privada. Se recomienda proteger al constructor a no ser que la clase esté sellada, en cuyo caso éste deberá marcarse como privado. Para restaurar el estado del objeto, sólo hay que recuperar los valores de las variables de SerializationInfo con los nombres utilizados durante la serialización. Si la clase base implementa ISerializable, debe llamarse al constructor base para permitir que el objeto base restaure sus variables.

Al derivar una clase nueva de una que implementa ISerializable, la clase derivada debe implementar tanto el constructor como el método GetObjectData si tiene variables que necesitan serializarse. El miniprograma de código siguiente muestra cómo realizar este procedimiento utilizando la clase MyObject, mostrada previamente.

[Serializable]
public class ObjectTwo : MyObject
{
public int num;

public ObjectTwo() : base()
{
}

protected ObjectTwo(SerializationInfo si, StreamingContext context) :
base(si,context)
{
num = si.GetInt32("num");
}

public override void GetObjectData(SerializationInfo si,
StreamingContext context)
{
base.GetObjectData(si,context);
si.AddValue("num", num);
}
}
No olvide llamar a la clase base en el constructor de deserialización. De lo contrario, el constructor de la clase base no será llamado nunca y el objeto no se construirá totalmente tras la deserialización.

Los objetos se reconstruyen desde el interior. Durante la serialización, los métodos de llamada pueden ocasionar efectos secundarios no deseados, ya que es probable que éstos hayan llamado a referencias de objetos que no han sido deserializados antes de la llamada. Si la clase que se está deserializando implementa IDeserializationCallback, el método OnSerialization será llamado automáticamente cuando la totalidad del gráfico del objeto se deserialice. En este punto, se han restaurado todos los objetos secundarios mencionados. Una tabla hash es un ejemplo típico de una clase difícil de deserializar sin utilizar la escucha de evento descrito anteriormente. Resulta fácil recuperar los pares clave/valor durante la deserialización. Sin embargo, la agregación de estos objetos en la tabla hash puede ocasionar problemas, dado que no existe garantía de que las clases derivadas de la tabla se hayan deserializado. Por tanto, no es recomendable utilizar los métodos de llamada en una tabla hash.

Pasos en el proceso de serialización
Cuando se llama al método Serialize en un formateador, la serialización del objeto funciona según las siguientes reglas:

Se realiza una comprobación para determinar si el formateador tiene un selector suplente. Si es así, compruebe que éste controla objetos del tipo especificado. Si éste es el caso, se llama a ISerializable.GetObjectData en el selector suplente.
Si no existe un selector suplente o no controla el tipo especificado, se realizará una comprobación para determinar si el objeto está marcado con el atributo Serializable. En caso contrario, se utilizará SerializationException.
Si está marcado correctamente, compruebe si el objeto implementa ISerializable. Si es así, se llamará a GetObjectData en el objeto.
Si no implementa ISerializable, se utilizará la norma de serialización predeterminada, que consiste en serializar todos los campos no marcados como NonSerialized.
Control de versiones
.NET Framework admite el control de versiones y la ejecución página tras página. Todas las clases funcionarán en las distintas versiones si no se cambian las interfaces. Dado que las serializaciones tratan con variables miembro y no interfaces, preste atención al agregar o eliminar variables miembro en clases que se serializarán en las distintas versiones. Éste es el caso para clases que no implementan ISerializable. Cualquier cambio de estado en la versión actual, como la agregación de variables miembro, el cambio del tipo de variables o de sus nombres, significará que los objetos existentes del mismo tipo no podrán deserializarse correctamente si se serializaron en una versión anterior.

Si el estado de un objeto requiere cambiar versiones, los autores de clase tienen dos posibilidades:

Implementar ISerializable, lo que permite tomar un control preciso de los procesos de serialización y deserialización. Como resultado, se podrá agregar e interpretar correctamente el estado futuro durante la deserialización.
Marcar las variables miembro no esenciales con el atributo NonSerialized. Esta opción sólo debe utilizarse cuando se esperen cambios mínimos entre las diferentes versiones de una clase. Por ejemplo, al agregar una nueva variable a una versión posterior de una clase, la variable no puede marcarse como NonSerialized con el fin de asegurar que se mantenga compatible con las versiones anteriores.
Instrucciones de serialización
Utilice la serialización al diseñar nuevas clases, dado que una clase no puede serializarse tras compilarse. Algunas preguntas importantes: ¿debo enviar esta clase a los dominios de la aplicación?, ¿se utilizará esta clase con servicio remoto en algún momento?, ¿qué harán los usuarios con esta clase? Quizás deriven una nueva clase de la mía que necesita serializarse. Cuando tenga dudas, marque la clase como serializable. Es aconsejable marcar todas las clases como serializables a no ser que:

No se extiendan por ningún dominio de la aplicación. Si la serialización no es necesaria y la clase debe cruzar por un dominio de aplicación, derive la clase de MarshalByRefObject.
La clase almacena punteros especiales que sólo se aplican a la instancia actual de la clase. Si una clase contiene memoria no administrada o identificadores de archivos, por ejemplo, asegúrese de que estos campos estén marcados como NonSerialized o no deserialice la clase en ningún caso.
Algunos de los miembros de datos contienen información sensible. En este caso, será recomendable implementar ISerializable y serializar sólo los campos requeridos.

Aspectos basicos de los XML Web Services

2005-11-09T14:59:06+00:00

Definición de XML Web Services
Los servicios XML Web Services son los elementos fundamentales en la evolución hacia la computación distribuida a través de Internet. Se están convirtiendo en la plataforma de integración de aplicaciones gracias a los estándares abiertos y al énfasis en la comunicación y colaboración entre personas y aplicaciones. Las aplicaciones se crean utilizando los servicios XML Web Services múltiples de origen distinto que funcionan conjuntamente, sin importar su ubicación o la forma en que se implementaron.

Existen tantas definiciones de los servicios XML Web Services como empresas que los diseñan. Sin embargo la idea general es:

Los servicios XML Web Services ofrecen funciones muy útiles a usuarios del medio Web ya que emplean un protocolo Web estándar que, en casi todos los casos, es SOAP.
Los servicios XML Web Services permiten describir sus interfaces con suficiente detalle para que el usuario diseñe una aplicación cliente que permita comunicarse con ellas. Esta descripción se proporciona normalmente en un documento XML denominado WSDL (lenguaje de descripción de servicios Web).
Los servicios XML Web Services se registran para que los futuros usuarios los encuentren fácilmente. Este registro se realiza a través de UDDI (descripción, descubrimiento e integración universales).
En este artículo comentaré estas tres tecnologías pero primero quiero explicar por qué son tan importantes los servicios XML Web Services.

Una de las principales ventajas de la arquitectura de los servicios XML Web Services es que permite que los programas escritos en lenguajes y plataformas diferentes puedan establecer comunicación entre sí de forma estándar. Seguro que los programadores que trabajan en esta industria desde hace tiempo se preguntarán:¿No era esto lo mismo que nos prometieron con CORBA y, anteriormente, con DCE? ¿Cómo es posible que los servicios XML Web Services sean diferentes?" La primera ventaja de los servicios XML Web Services es que SOAP es bastante menos complejo que sus antecesores, de modo que resulta más fácil que una implementación cumpla con los estándares de SOAP. Paul Kulchenko publica una lista de implementaciones SOAP en: http://www.soapware.org/directory/4/implementations (en inglés) que contiene al menos 79 entradas. Las grandes empresas de software diseñan implementaciones SOAP pero también existen otras muchas construidas y mantenidas por un único programador. Otra ventaja importante es que los servicios XML Web Services funcionan con protocolos Web estándar, como XML, HTTP y TCP/IP. Muchas empresas disponen ya de una infraestructura Web, así como de personal y conocimientos para mantenerla, de modo que el coste de entrada a estos servicios es mucho menor que con las tecnologías antecesoras.

He definido antes un servicio XML como un servicio de software que se muestra en Web a través de SOAP, se describe con un archivo WSDL y se registra en UDDI. La siguiente pregunta lógica es: "¿Qué se puede hacer con los servicios XML Web Services?" Los primeros servicios solían ser fuentes de información que podían incorporarse fácilmente en aplicaciones para cotizaciones bursátiles, previsión del tiempo, resultados deportivos, etc. Resulta fácil imaginar el tipo de aplicaciones que podían crearse para analizar e incluir información importante y presentarla en modos diferentes. Por ejemplo, en una hoja de cálculo de Microsoft® Excel en la que se resumiría la siguiente información: acciones, plan de pensiones, cuentas bancarias, préstamos, etc. Si esta información estuviera disponible a través de servicios XML Web Services, Excel podría actualizarla continuamente. Parte de dicha información sería gratuita y otra necesitaría que el usuario se subscribiera al servicio. La mayor parte de esta información está disponible ahora en Internet. Sin embargo, los servicios XML Web Services posibilitan que sea más fácil y fiable tener acceso a ella.

La exposición de aplicaciones existentes como servicios XML Web Services permitirá que los usuarios creen aplicaciones más potentes que utilicen estos servicios XML Web como elementos constituyentes. Por ejemplo, un usuario puede desarrollar una aplicación de compra para obtener automáticamente de varios fabricantes información sobre precios, permitir seleccionar un fabricante, enviar el pedido de compra y realizar un seguimiento hasta el momento de recibir el envío. Es posible que la aplicación del fabricante, además de exponer sus servicios en Web, utilice los servicios XML Web Services para comprobar el crédito del cliente, cargar el importe del envío en su cuenta y enviar el pedido a través de una empresa de transportes.

En el futuro, algunos de los servicios XML Web Services más interesantes admitirán aplicaciones que utilicen el medio Web para realizar tareas que no pueden realizarse actualmente. Por ejemplo, uno de los servicios que el proyecto Microsoft .NET My Services admitirá es un servicio de calendario. Así, si su dentista y mecánico expusieran sus calendarios mediante este servicio XML Web, usted podría concertar citas en línea desde su calendario para una limpieza dental y mantenimiento rutinario. Y es fácil imaginar los cientos de aplicaciones que podrían diseñarse cuando se tiene el conocimiento para programar el medio Web.

Para obtener más información sobre los servicios XML Web Services y las aplicaciones que le ayudan a crearlos, consulte la página principal de los servicios Web en MSDN.

SOAP
SOAP es el protocolo de comunicaciones para los servicios XML Web Services. Cuando se describe SOAP como un protocolo de comunicaciones, muchas personas piensan en DCOM o CORBA y se preguntan "¿Cómo realiza SOAP la activación de objetos?" o "¿Qué servicio de nombres utiliza SOAP?" Mientras es posible que una implementación SOAP incluya estos datos, el estándar SOAP no los especifica. SOAP define el formato XML para mensajes. Si tiene un fragmento creado correctamente en XML e incluido en un par de elementos SOAP, dispondrá ya de un mensaje SOAP. Sencillo, ¿verdad?

Existen otras partes en la especificación SOAP que describen cómo representar los datos de un programa como XML y cómo utilizar SOAP para realizar llamadas a procedimiento remoto (RPC). Estas partes opcionales de la especificación se utilizan para implementar aplicaciones estilo RPC en las que el cliente envía un mensaje SOAP que contiene una función a la que se puede llamar, además de los parámetros para pasar a la función. El servidor, por su parte, devuelve un mensaje con los resultados de la función ejecutada. Casi todas las implementaciones actuales de SOAP admiten aplicaciones RPC porque los programadores que trabajan con aplicaciones COM o CORBA conocen el estilo RPC. SOAP admite también aplicaciones con estilo de documento en las que los mensajes SOAP cubren un documento XML. Las aplicaciones SOAP con estilo de documento son muy flexibles. Muchos nuevos servicios XML Web Services aprovechan esta flexibilidad para diseñar servicios que sería difícil implementar mediante RPC.

La última parte opcional de la especificación SOAP define los contenidos de un mensaje HTTP que contiene un mensaje SOAP. Este enlace HTTP es importante porque casi todos los sistemas operativos actuales, y otros no tan actuales, admiten HTTP. Este enlace es opcional pero casi todas las implementaciones SOAP lo admiten porque es el único protocolo estandarizado para SOAP. Por esta razón, existe la falsa idea general de que SOAP necesita HTTP. Algunas implementaciones admiten MSMQ, series MQ, SMTP o TCP/IP. Sin embargo, la mayoría de los servicios XML Web Services utilizan HTTP porque es ubicuo. Dado que HTTP es un protocolo imprescindible para el medio Web, muchas empresas disponen de infraestructuras de redes que lo admiten y personal con conocimientos y experiencia para gestionarlo. En la actualidad ya se encuentran disponibles la seguridad, el control y la infraestructura de equilibrio de cargas para HTTP.

A la hora de empezar a trabajar con SOAP, es importante entender la diferencia entre la especificación SOAP y la variedad de implementaciones de esta especificación. Muchos programadores que utilizan SOAP no escriben mensajes SOAP directamente, sino que utilizan un SOAP Toolkit para crear y analizar mensajes SOAP. Generalmente, estos kits de herramientas traducen llamadas de función de algún tipo de lenguaje a un mensaje SOAP. Por ejemplo, Microsoft SOAP Toolkit 2.0 traduce llamadas de función COM a SOAP y el kit de herramientas de Apache traduce funciones de llamadas JAVA a SOAP. Los tipos de llamadas de función y los tipos de datos de los parámetros admitidos varían en cada implementación SOAP, de forma que es posible que una función que trabaja con un kit de herramientas no funcione con otro. Esto no es una limitación de SOAP, sino de la implementación específica que utilice en cada caso.

La característica más notable de SOAP es que se ha implementado en diferentes plataformas de hardware y software, lo que significa que puede utilizarse para enlazar sistemas dispares dentro y fuera de su empresa. En el pasado se realizaron muchos intentos para conseguir un protocolo de comunicaciones común que pudiera usarse en la integración de sistemas. Sin embargo, ningún intento se ha generalizado tanto como SOAP. ¿Por qué? Porque SOAP es más pequeño y sencillo de implementar que muchos de los protocolos anteriores. Por ejemplo, se tardaron años en implementar DCE y CORBA, de modo que sólo unas pocas implementaciones llegaron a comercializarse. Por su parte, SOAP utiliza analizadores XML y bibliotecas HTTP existentes para realizar la mayor parte del trabajo más complicado; por ello, una implementación SOAP puede estar terminada en cuestión de meses. Ésta es la razón por la que hay disponibles más de 70 implementaciones SOAP. No obstante, SOAP no consigue los mismos resultados que DCE o CORBA pero su sencillez y características posibilitan que esté disponible rápidamente.

La ubicuidad de HTTP y la sencillez de SOAP los convierte en una base perfecta para implementar servicios XML Web Services que pueden llamarse desde prácticamente cualquier entorno. Para obtener más información sobre SOAP, consulte la página principal de SOAP en MSDN.

Aspectos sobre la seguridad
Una de las primeras preguntas que se cuestiona un usuario nuevo es cómo protege SOAP la seguridad. En los primeros momentos de su desarrollo, SOAP era considerado como un protocolo basado en HTTP y, por tanto, se asumía que la seguridad de HTTP sería adecuada para SOAP. Además, existen miles de aplicaciones Web que se ejecutan actualmente utilizando la seguridad de HTTP. Por esta razón, el estándar SOAP actual supone que la seguridad es un problema de transporte y no comenta nada sobre los problemas de seguridad.

La seguridad empezó a ser un problema en el momento en que SOAP se convirtió en un protocolo más generalizado que se ejecutaba en múltiples medios de transporte. Por ejemplo, HTTP proporciona diferentes modos de autenticar qué usuario realiza una llamada SOAP. Pero, ¿cómo se propaga esa identidad al dirigirse el mensaje desde HTTP a un transporte SMTP? SOAP se diseñó como un protocolo de base; afortunadamente existen especificaciones en los textos para diseñar en SOAP que proporcionan más características de seguridad para servicios Web. El artículo sobre la especificación WS-Security define sistemas de cifrado completos y el artículo WS-License define técnicas que protegen la identidad de la persona que llama y aseguran que sólo usuarios autorizados puedan utilizar un servicio Web.

WSDL
WSDL es el acrónimo de Web Services Description Language (lenguaje de descripción de servicios Web). Para nuestros objetivos, se puede definir un archivo WSDL como un documento XML que describe un conjunto de mensajes SOAP y la forma en la que éstos se intercambian. En otras palabras, WSDL es a SOAP lo que IDL es a CORBA o a COM. WSDL es XML (es decir, se puede leer y modificar en gran parte de los casos) y es generado y utilizado por software.

Para comprobar el valor WSDL, imagine que desea llamar a un método SOAP que le proporciona uno de sus socios comerciales. Podría solicitarle algunos ejemplos de mensajes SOAP y escribir su propia aplicación para crear y utilizar mensajes que se mostraran de forma similar a los ejemplos. Esto, sin embargo, puede dar lugar a errores. Por ejemplo, si ve el Id. 2837 de un cliente, supondrá que es un número entero en lugar de una cadena. WSDL especifica qué debe contener un mensaje de solicitud y cómo se verá el mensaje de respuesta en una notación clara.

La notación que utiliza un archivo WSDL para describir formatos de mensaje se basa en el estándar XML. Esto significa que es un idioma de programación neutral y basado en estándares, lo cual es perfecto para describir interfaces de servicios XML Web Services que pueden abrirse desde una gran variedad de plataformas y lenguajes de programación. Además de describir el contenido de un mensaje, WSDL define el lugar en el que está disponible el servicio y qué protocolo de comunicaciones se utiliza para hablar al servicio. Esto significa que el archivo WSDL define todos los elementos necesarios para escribir un programa que pueda funcionar con un servicio XML Web. Existen varias herramientas disponibles para leer un archivo WSDL y generar el código necesario para establecer comunicación con un servicio XML Web. Algunas de las herramientas más útiles se encuentran en Microsoft Visual Studio® .NET.

Muchos de los actuales SOAP Toolkits incluyen herramientas para generar archivos WSDL desde interfaces de programas existentes. Sin embargo, hay pocas herramientas para escribir WSDL directamente y la compatibilidad para WSDL no es tan general como debería ser. No debería pasar mucho tiempo para que las herramientas que facilitan la creación de archivos WSDL, y posteriormente generan proxies y etiquetas como las herramientas COM IDL, formen parte de muchas implementaciones SOAP. En esa etapa, WSDL será el medio preferido para crear interfaces SOAP para los servicios XML Web Services.

Puede consultar una descripción excelente de WSDL y encontrar la especificación de WSDL en http://www.w3.org/TR/wsdl.

UDDI
UDDI (descripción, descubrimiento e integración universales) constituye las páginas amarillas de los servicios Web. Como en las páginas amarillas en papel, es fácil buscar una empresa que ofrece los servicios que necesita, leer acerca del servicio ofrecido y ponerse en contacto con una persona para solicitar más información. Por supuesto, puede ofrecer un servicio Web sin tener que registrarlo en UDDI, al igual que si, por ejemplo, abriera un negocio en el sótano de su casa y confiara en la publicidad del "boca a boca". Si quisiera ampliar sus expectativas en el mercado, necesitaría UDDI para que sus clientes lo encontraran.

Una entrada en un listín UDDI es un archivo XML que describe un negocio y los servicios que ofrece. Cada entrada tiene tres partes. Las "páginas blancas" describen los datos de la empresa, como nombre, dirección, información de contacto, etc. Las "páginas amarillas" incluyen las categorías industriales basadas en taxonomías estándares, como la NAICS (North American Industry Classification System) y la SIC (Standard Industrial Classification). Las "páginas verdes" describen la interfaz del servicio con información suficiente para que alguien escriba una aplicación para usar un servicio Web. Los servicios se definen por un documento UDDI denominado Type Model o tModel. En muchos casos, tModel contiene un archivo WSDL que describe una interfaz SOAP a un servicio XML Web; tModel es suficientemente flexible para describir prácticamente cualquier tipo de servicio.

El listín UDDI incluye también diferentes formas de búsqueda de servicios para que puede diseñar sus propias aplicaciones. Por ejemplo, puede buscar proveedores de un servicio en una ubicación concreta o negocios de un tipo determinado. El listín UDDI le proporcionará la información, personas de contacto, enlaces y datos técnicos para que evalúe los servicios que satisfacen sus necesidades.

UDDI permite buscar negocios de los que desee obtener servicios Web. Si conoce con quién quiere realizar negocios pero desconoce los servicios que ofrece el artículo WS-Inspection permite examinar una recopilación de los servicios XML Web Services ofrecidos en un servidor determinado para buscar los que satisfagan sus necesidades.

Si desea ver más información sobre UDDI, consulte http://www.uddi.org/about.html (en inglés).

Conclusión
Hemos comentado cómo hablar con los servicios XML Web Services (SOAP), cómo se describen estos servicios (WSDL) y cómo encontrarlos (UDDI). Éstas son las especificaciones básicas que proporcionan los pilares para la integración y agregación de una aplicación. A partir de aquí, las empresas construyen soluciones y obtienen resultados reales.

Si bien se han realizado muchos progresos para convertir los servicios XML Web Services en una realidad, queda mucho por hacer. Actualmente, las personas obtienen resultados satisfactorios de estos servicios pero quedan aspectos pendientes como la seguridad, la administración operativa, las transacciones, el intercambio seguro de mensajes, etc. La arquitectura global de los servicios XML Web Services ayudará a que estos servicios avancen al siguiente nivel proporcionándoles un modelo coherente y general para agregar nuevas capacidades avanzadas a estos servicios para que sean modulares y ampliables.

Los módulos para seguridad (WS-Security y WS-License) mencionados anteriormente forman parte de las especificaciones en la arquitectura global de servicios Web. Las necesidades de la administración operativa, como el enrutamiento de mensajes entre varios servidores y la configuración dinámica de éstos para procesar, forman también parte de la arquitectura global de los servicios Web, y los cumple WS-Routing y WS-Referral. A medida que crezca la arquitectura global de los servicios Web, se irán introduciendo especificaciones para éstas y otras necesidades.

Estadísticas Web

AVG...una buena opcion en Antivirus.

2005-10-24T15:53:38+00:00

AVG....Una buena opcion en Antivirus.
Tiene una versión totalmente gratuita y una de pago
Sin dudar es el mejor antivirus gratuito que se puede encontrar. Posee la versión gratuita y de paga; en su versión gratis ofrece la misma seguridad que la paga, pero con menos posibilidades de configuración. Es excelente para uso personal y especialmente para computadoras que no son potentes. Su monitor para el escaneo de virus en tiempo real utiliza muy pocos recursos.
Por ser la versión gratuita, hay muchas características que desearían tener los expertos que no están, desde consultas online las 24 horas y otras herramientas para mejor detección, pero para uso personal es altamente recomendado.

Prueba la nueva interfaz de Hotmail

2005-10-11T17:25:15+00:00

Lista para ser probada públicamente se encuentra la nueva versión de Hotmail, cuyo nombre clave 'Kahuna' fue reemplazado por un sencillo 'Mail Beta'. El servicio de e-mail de Microsoft fue reconstruido totalmente para incorporar tecnologías como Ajax, Atlas Framework y FireAnt, que le proporcionen mayor versatilidad.

Clic aqui para ingresar.

Windows v/s Linux ... Puntos Objetivos.

2005-10-11T17:03:26+00:00

Windows VS Linux

Navegando por la red he leido este articulo que para mi ha sido uno de los mas objetivos dentro de las comparaciones entre Linux y Windows.

¿Qué es lo que da rentabilidad a una empresa?.
¿Qué es lo que da rentabilidad a una empresa?.
¿Alguna vez te has puesto a pensar que los modelos de económicos que rigen el comportamiento de la mayoría de las empresas también determinan si nuestra inversión, esfuerzo y trabajo generan valor suficiente para producir márgenes de ganancia?.

El mejor amigo que puedes tener es un administrador de TI que conozca la fórmula mágica para reducir gastos en su área, para lo cual necesita conocer muy bien las características de cada una de las soluciones y las ventajas administrativas de cada proveedor. Pero al final la decisión es tuya, y como sabemos que tú también necesitas estar informado, preparamos este documento con las características que tienes que considerar para instalar tu solución, sin dejarte convencer por palabras como gratis y sin dejar que el exceso de publicidad afecte tu relación.

Round 1
El fenómeno del código abierto.
Luego de ser considerado durante años como el monstruo en espera de venganza dentro de la industria, las soluciones de tecnología basadas en código abierto han crecido lo suficiente como para convertirse en una alternativa sólida que compite con carácter de igual contra otros monstruos del desarrollo de software como Microsoft.

Es probable que la batalla por la preferencia de los clientes de servidores para empresas viva su mejor momento. Un indicativo confiable para hacer esta aseveración es la ola de análisis y estudios de mercado que distintas firmas han llevado a cabo para determinar cuál es la mejor opción; pero más allá de los análisis, existen datos duros que confirman que si bien los números generales ponen en ventaja a Microsoft, los usuarios se rinden en mayor proporción al encanto del código abierto.

Por ejemplo hasta febrero del año pasado, 140 compañías norteamericanas utilizaban servidores con programas de código abierto. A lo largo de ese año, 60% de las compañías declararon su interés en instalar o evaluar detenidamente la posibilidad de migrar sus servidores a una plataforma de código abierto, la mayoría esperando que este ajuste se reflejara en una reducción de costo.

Según los representantes de cada una de las empresas en un sondeo general, la mayoría manifestó su interés en migrar los sistemas en busca de ahorro, 86% indicó que su interés estaba impulsado por el bajo costo de mantenimiento y 77% reconoció que las características de los programas basados en programación de código abierto se reflejarían en su costo total de propiedad.

Otro indicador, que ve está más ligado a cubrir nichos de mercado que a satisfacer necesidades es el crecimiento de las áreas de servidores en las grandes marcas. De pronto todos quisieron montar soluciones y para no comprometer la inversión decidieron incluir ambos sistemas operativos para facilitar la decisión de cada cliente.

Según Paul Anderson analista de IDC, “no ha existido un mejor momento para el código libre, dejó de ser una alternativa para convertirse en una solución que puede aportar mucho éxito a modelos de negocios específicos”. Este crecimiento favorece a la industria en todos los sentidos porque enriquece el espectro de oportunidades para los usuarios.

Ganador: todos los usuarios de sistemas basados en Linux.

El código abierto es utilizado por la mayoría de las compañías en EUA en 2004

Utilizándolo hoy 46%
No planean implementarlo 39%
Planea implementarlo 14%

Base de encuesta: 140 firmas en Norteamérica. Fuente: Forrester Research Inc.
Round 2
Capacidad de reacción ante errores
Linux considera que la información presentada por el estudio de Forrester es falsa y tendenciosa. Lo cierto es que hay un punto muy claro que los usuarios de Linux critican en este estudio: Forrester no tomó en cuenta el nivel de gravedad de los errores que se declaran.

Según su percepción, la gravedad de los errores de Windows es más peligrosa que los que detecta un sistema Linux. A final de cuentas, lo trascendente es que la gravedad del error disminuye en proporción al tiempo de respuesta en que es resuelto.

Empresas como Debian, MandrakeSoft, Red Hat y SuSE Linux tampoco están de acuerdo con los resultados de Forrester, donde sus análisis prueban que los sistemas operativos de Microsoft reaccionan y corrigen los problemas y errores más rápido en sistemas basados en Windows. Este estudio utiliza cifras y conceptos que sólo los técnicos en TI conocen y pueden interpretar, aunque también prepararon comparativos con otras magnitudes con el mismo nivel de importancia y que son más simples de entender, por ejemplo: Cuando un error que requiere la atención del proveedor de servicio, sólo se necesitan 25 días hábiles a partir del momento en que se da aviso, para que Microsoft pueda corregir el problema que provoca su softwate.

En cambio, se requieren 57 días para que compañías como Red Hat o Debian hagan la corrección en sistemas basados en Linux, SuSE Co. necesita 74 días para dar respuesta, mientras que Mandrakesoft, el más lento de todos, se toma hasta 82 días como máximo.

Ganador: En este round hemos declarado un empate, ya que los responsable de tomar la decisión de lo que vale la estabilidad de los servidores son los mismos usuarios. Cada departamento a cargo debe evaluar el beneficio costo/tiempo de acuerdo con sus necesidades y recursos.

Hay que dejar claro que el estudio se refiere a errores que alteran el funcionamiento general de los servidores, porque cuando se trata de errores graves ambas compañías tienen reglas muy estrictas de prioridad, de manera que cuando un error se declara como crítico, la corrección se lleva a cabo de manera rápida, por lo general en algunas horas, mientras que las fallas que se declaran como ‘errores sin consecuencia seria’ pueden esperar un poco más. En términos generales y a largo plazo el soporte más económico, menos severo y constante en términos de errores comunes es Windows.

Deseo de reducir los costos de administración adoptando una solución de código abierto.

Bajo costo de adquisición 86%
Bajo costo de Propiedad 77%
Alternativas de Hardware 49%
Alternativas de Software 41%
Mejor seguridad 31%
Familiar para los desarrolladores 24%
Máxima calidad 24%
Otros beneficios no mencionados 16%

Estudio realizado a 85 firmas norteamericanas que utilizan software de código libre (se aceptaron respuestas múltiples)
Round 3
Valor actual y proyección a futuro
Para mostrar el panorama de esta batalla en el futuro, Yankee Group realizó un análisis con empresas que reconocen que los sistemas basados en Linux son una alternativa interesante para el mercado.

Como parte del sondeo que medió la confianza de los potenciales usuarios, los participantes manifestaron que que 90% de las 300 empresas que cuentan con más de 10 mil empleados, no están convencidos en hacer un cambio de sistema operativo Widows a Linux. La causa común responde a factores económicos. A pesar de lo que la gran mayoría piensa, la transición es muy costosa, compleja y larga.

La relación de resultados prueba que (en estudios con escenarios controlados) la migración a Linux no ofrece resultados inmediatos, que en algunos casos son necesarios para este tipo de empresas. Los casi mil dirigentes y responsables de los departamentos de informática que fueron cuestionados coincidieron en que este panorama les parecía preocupante. En realidad no es nada complicado entender que cada empresa funciona con modelos de negocios distintos, por lo tanto es muy aventurado comprometer la idea de desempeño del código libre por esta aceveración.

De acuerdo con Laura Didio, encargada del grupo de analistas que desarrollaron el documento The Cost and Risks of Open Source para The Yankee Group: “Para las grandes empresas, la implementación de un sistema operativo distinto al que está en uso significa un gran riesgo. Si se trata de migrar una plataforma Windows a Linux el costo es de tres a cuatro veces más alto y toma en promedio tres veces más tiempo que si se tratara de implementar una actualización común de Windows a una versión más reciente.”

El estudio concluye que los servidores basados en Linux no superarán los sistemas operativos Windows, pero reconocen que cada vez es más común identificar atractivos beneficios en los sistemas basados en código abierto, al grado de que es muy probable que en menos de dos años, la base instalada de usuarios de Linux se incremente 3.2%, contra 1.8% de Apple con sus sistemas Mac OS.

Round 4
El mejor precio
Aún cuando el costo del sistema operativo Linux es en si mismo gratuito y exista la percepción de que es muy económico en términos de desarrollo personalizado. En términos reales y según la percepción de Gardner los costos adicionales en materia de servidores como programas de integración, infraestructura de administración y soporte agregado suman un costo de propiedad total superior a la de Windows.

Por otro lado, en tu análisis de compra, actualización o conversión de software debes contemplar los costos únicos y los gastos por concepto de servicios recurrentes. Los análisis realizados hasta la fecha en esta área demuestran que el precio que hay que pagar por dar soporte de TI y de operaciones comunes de usuario final son en gran parte los responsables del alto costo en el periodo de vida útil de un sistema.

No importa que plataforma utilices, ya que esta constante es universal y sólo varía en proporción al tipo y tamaño de empresa. Si quieres reducir este tipo de gastos, el software que elijas debe ofrecer:
— Un programa muy completo de entrenamiento y actualización para poner a tus empleados al día. El modelo que adquieras debe ofrecerte información de calidad para los miembros de tu oficina de TI y de los usuarios finales.
— Debe establecer una gran diferencia contra su versión anterior, de manera que el nuevo software sea más simple, más ligero, con soluciones más rápidas y los ingredientes necesarios para que tu equipo de soporte lo pueda dominar si dificultad. La velocidad y control del software de los servidores se manifiesta también como una manera de ahorrar.
— Debe garantizar soporte y compatibilidad para implementar las exitosas prácticas que reflejarán su eficacia en la disminución de tus costos. La mayoría de estas prácticas son procedimientos para administrar tu propio sistema de la mejor manera.

El ganador de este round es Microsoft, pues es una elección más económica si consideras el ciclo de vida útil de un sistema operativo. Además tiene varias características incluidas que reducen la complejidad de algunas soluciones de código libre. Permite implementar herramientas externas para mejorar la estructura de tu organización. En este sentido hay que reconocer que la base instalada de usuarios de Microsoft a nivel mundial es una ventaja para la certificación y el correcto adiestramiento de los miembros de tu staff. En las tablas de relación de componentes puedes comparar el costo de las características mínimas que pueden ayudar a reducir tus costos.

Consejos para reducir costos

Plantea una estrategia de código abierto
La decisión de instalar o no tecnologías de código abierto dependen de la necesidad de cada empresa. Considera que las decisiones que tomes impactarán varias áreas de tu organización, desde la elección de las aplicaciones que se la darán a los negocios, hasta los efectos legales, regulatorios y de riesgo financiero para tu organización.

Decide cómo vas a utilizar la tecnología de código abierto y la manera como esperas que estas plataformas se van a utilizar, quien va a darte soporte, de qué manera van a garantizar la seguridad y la responsabilidad que vas a dejar a cargo de tu departamento de TI. Mantener los costos bajos implica un plan ejecutivo formal, con un conocimiento claro del objetivo de la empresa y le estrategia planteada para lograrlo.

Plantea una estrategia con software comercial
Antes de tomar cualquier decisión, evalúa las condiciones de tu empresa a largo plazo y consulta los costos de inversión y mantenimiento. Cuídate de los ingenieros de TI que se casan con soluciones mágicas universales y tampoco permitas que la publicidad impulse una decisión que no está bien estudiada.

Si tu empresa requiere una solución robusta, consulta con el proveedor de servicio la posibilidad de negociar contratos por tiempo, resultados, soporte y mantenimiento, te sorprenderías de saber todo lo que ellos pueden aportar a tu negocio.

Establece las reglas
¿Cuál es el modelo de licenciamiento que vas a seguir? Cuando se trata de soluciones de código abierto, es necesario pensar un poco más allá del beneficio del ahorro, por ejemplo: si concedes privilegios de acceso y mantenimiento a algún miembro del staff y éste se va, ¿el proveedor de servicios estará listo para responder con ayuda inmediata?.

Define las fechas y las condiciones de las pruebas de seguridad y establece las reglas de control de desarrollo y soporte interno, después de todo, el soporte no sólo es necesario e importante, es el verdadero elemento que te puede ayudar a economizar, sobre todo si lo pones en proporción al costo de las soluciones comerciales. Al final aquellos que se aventuran por primera vez al código abierto terminan por buscar ayuda de especialistas con soluciones comerciales y a la larga el costo es más alto.

La decisión de la plataforma que utilizarás en tu negocio no tiene tonos medios. Las aventuras hacia una u otra solución toman tiempo y cuestan mucho dinero. Como todo esto se trata de encontrar alternativas para ahorrar, nuestro mejor consejo es dedicar tiempo suficiente a la evaluación de tus necesidades contra la oferta de la solución.

Las licencias y sus costos
El argumento más atractivo del código abierto es que ‘su aplicaciones no tienen costo’ y es cierto, existen modelos para compañías específicas en las que el costo pude ser extremadamente bajo o gratuito. El problema no está con las licencias sino con quien las maneja.

Si tu modelo de negocios se adapta a las soluciones de código abierto pon atención a los detalles de licenciamiento, por ejemplo, si por alguna razón necesitas modificar el código de tu modelo de negocios y tienes que intervenir la programación ¿el contrato te protege contra las reglas de retroalimentación y distribución de la comunidad de código abierto?, no es necesario comprometer a tus ingenieros de TI con miles de cláusulas de protección; se trata de que conozcas los procedimientos y costumbres del código abierto para que una solución no se convierta en el dolor de cabeza de tu plataforma.

El hecho de que el costo de licenciamiento y soporte no varíe, nunca falta que una nueva actualización esté acompañada por equipo o software de soporte que representa otro gasto. A diferencia del caso de Linux, es más complicado acostumbrarse a pagar licencias que a establecer normas de orden desde el principio.

Conoce el costo de mantenimiento
Contrario a lo que todo el mundo cree, este departamento marca una diferencia radical en la selección de la tecnología a elegir. Las empresas, de manera general, consideran que el área que representa el mantenimiento y soporte para servidores es la más costosa, pero existen detalles importantes en ambas plataformas.

Las compañías con Linux tienden a involucrarse más con las soluciones de mantenimiento lo que representa un gasto extra no considerado para poner al día a tus ingenieros de TI. El costo del entrenamiento varía según el tamaño y las necesidades de cada empresa. Por otro lado, algunos vendedores de Linux ofrecen paquetes de consultoría y servicios muy atractivos, analiza el beneficio que puede traer a tu negocio.

Del lado del costo para software comercial, los costos de mantenimiento y actualización, aunque están controlados e incluso pactados desde que se hace la contratación no dejan de representar una cifra con varios ceros. La ventaja favorita de los profesionales en este rubro es que el software necesario para dar soporte al proyecto esta disponible prácticamente en cualquier momento.

Los modelos comerciales tienen que satisfacer necesidades distintas para diferentes modelos de negocio, lo que los convierte en soluciones muy completas. El conocimiento de la plataforma es una ventaja que vale oro cuando las cosas salen mal o cuando es necesario implementar nuevas y mejores características.

Mitos y Realidades

El tema de los sistemas operativos para servidores se ha convertido en una lucha que genera tensión tras bambalinas a nivel de empresas de consumo, desarrolladores y compañías especializadas que se encargan de realizar estudios comparativos entre las dos plataformas.

La polémica sobre la veracidad de los resultados no se hace esperar y mientras las estrategias de publicidad de las compañías con soluciones comerciales buscan convencer a los usuarios, los desarrolladores de cada sistema compiten de manera abierta para mejorar la concepción que los usuarios tienen de cada SO. Después de todo, lo importante no es premiar al mejor, sino descubrir sobre cual vale la pena hacer de nuestra la inversión del que se adapta mejor a mi empresa y mis necesidades.

Lo que se dice: en el área de seguridad, el tamaño de Windows es su peor enemigo, porque su tamaño y presencia mundial lo convierten en un objetivo más fácil de atacar. Mientras que los usuarios de Linux son tan pocos, que ni siquiera necesitan enterarse de los ataques que se vuelven moda en Windows.

Lo que es: es evidente que una base instalada de usuarios mayor represente un riesgo mayor, pero en realidad lo que convierte al sistema en una amenaza es su mismo diseño, que lo convierte en un objetivo vulnerable para provocar graves problemas. En cambio, el diseño de Linux no es tan vulnerable en ese sentido. No importa que tan exitoso o simple sea un sistema si en algún momento puede ser vulnerado por elementos de administración visualmente agradables que a final de cuentas no son tan necesarios. La ventaja de Linux en ese sentido, es que en un plano comparativo, recibe ataques que tienen un nivel de riesgo mucho menor, lo que indirectamente, también afecta a Windows.

Lo que se dice: dado que Linux está basado en código abierto, es más fácil atacarlo y dañarlo. Cualquiera que programa en Linux puede descifrar el código y manipularlo. En cambio, los códigos de Windows son más seguros gracias a marcas de protección como ‘blueprints’ que son celosamente cuidadas y protegidas por Microsoft.

Lo que es: a pesar de la protección, la tendencia de los ataques actuales es dominada por virus que están programados para sistemas basados en Windows, como los troyanos, gusanos y demás programas ejecutables maliciosos. En la otra mano tenemos el modelo Linux de código abierto y su aparente simpleza para detectar, aislar, eliminar y corregir problemas.

En realidad la ventaja es tan simple como poco relevante. El esquema modular como se configuran los servidores de código abierto facilitan al revisión de amenazas de virus, por lo tanto también hacen más sencilla la identificación y corrección. A diferencia de la paranoia de seguridad de los SO Windows, que provoca una cultura de prevención más aguda, el código abierto responde a las amenazas de las redes con políticas de ‘seguridad por desconocimiento’ y confían en la ventaja que tienen su soluciones por no estar bajo la mirada de todo los consumidores.

Lo que se dice: la mayoría de los estudios que se realizaron en los últimos cinco años pueden probar que los sistemas basados en Windows generan errores muy simples de arreglar, lo que disminuye el tiempo de identificación y reparación para las empresas. Como estos errores se resuelven rápido, el tiempo de uso correcto de las soluciones de Microsoft es mayor a las que el código abierto puede ofrecer, situación que favorece a Linux. Lo que es: en los estudios más recientes, existen inconsistencias en algunas evaluaciones que se prestan a debate y polémica.

Si partimos del hecho de que se trata de medir condiciones similares en sistemas distintos, el cuestionamiento para definir al mejor sistema tendría que adaptarse a otro escenario. Lo que sí es mesurable es la pronta respuesta de los sistemas para reconocer errores. Hay estudios como el realizado por Forrester que ponderan la velocidad de reconocimiento y capacidad de solución a la gravedad de los errores y manera como interfieren con el trabajo del servidor.

Por otro lado, un estudio promovido por la asociación norteamericana Computer Emergency Readiness, se comparó la eficacia de los parches de seguridad para Windows Server 2003 y Red Hat Advance Server AS v3. El comparativo muestra que el parche de Microsoft presentó un total e 250 errores de vulnerabilidad, de las cuales 39 fueron definidas como muy graves. El parche para Advance Server AS v3 presentó un total de 46 errores de vulnerabilidad y sólo 3 fueron considerados como graves.

Al realizar un análisis detallado en ambos estudios encontramos que una vez más, las categorías de vulnerabilidad y reacción de emergencia dependen del tipo de aplicaciones que realiza el servidor, de acuerdo a la liquidez, tamaño y necesidades de cada empresa.

Entrevista
Platicamos con Sergio López, gerente de soluciones de infraestructura en HP sobre los detalles de su cada vez más reconocida estrategia para clientes interesados en servidores basados en SO Linux. A principio de 2004 IDC colocó a la compañía como líder del segmento en la región de Latinoamérica.

¿Qué ventaja ofrece un servidor basado en Linux sobre servidores Windows?
Por lo general estos sistemas dependen del ambiente de TI del cliente, y cada cliente es único y diferente, por lo que en menor o mayor grado puede ser más o menos ventajoso. En muchos otros casos Windows ofrece mayores ventajas. Creo que Linux empieza a consolidarse como una alternativa real de mercado y con esto los clientes son los que deciden si Linux o Windows o Unix o cualquier otro cubren de mejor manera sus necesidades.

¿Qué ventajas ofrece un servidor que trabaja con SO Linux?
Es muy común que los responsables de acondicionamiento de TI para empresas busquen las siguientes ventajas:

Ambiente operativo de clase empresarial estable y flexible
Utilizado en las plataformas estándar de la industria que como mínimo deben satisfacer una relación de menor costo de compra y mantenimiento, menor consumo de energía y disipación de calor, que aporte beneficios para la curva de desempeño de Intel, que reduzca de alguna manera la dependencia con respecto al propietario de la tecnología.
Disponibilidad creciente de aplicaciones de negocios
Alternativa al legado de los sistemas operativos UNIX o Microsoft
Reduce el TCO
La expansión de UNIX – impulsa la experiencia UNIX en empresas.
Una respuesta empresarial a la pregunta…“¿Cómo hacer más con menos?”
El tema de la seguridad es cada vez más recurrente. El término no sólo se refiere al concepto de evasión de ataque, también está relacionado con la idea de estabilidad. Estos factores son también importantes al momento de hacer una evaluación.

¿Qué tipo de usuario se adapta mejor a una solución en linux?
Linux está siendo adoptado por usuarios cuyo tema imperativo es el bajo costo. Aunque en términos generales esto depende según el tipo de usuario. En los grandes corporativos las decisiones están determinadas por otro tipo de criterios como la robustez y alta disponibilidad, el soporte y un excelente servicio.

¿HP tiene soluciones especiales para SO Linux?
La estrategia de HP con Linux estriba en ofrecer soluciones que cumplan con lo siguiente: Mejor ROI General

Linux en los Sistemas Estándar de la Industria Libertad de Elección gracias a
Tecnología basada en estándares
Asociaciones Comprobadas
Aplicaciones mejores en su clase
Soluciones Administradas Fin a Fin (End-to-End) Sin Preocupaciones gracias a
Servicios y Soporte Mundial HP
Administración de Fuente Abierta HP
Idemnización y Responsabilidad Final de HP.
¿En qué medida continuarán involucrándose con usuarios de Linux?
Estamos comprometidos con mantener nuestra posición en el segmento. Con base en esta estrategia, estamos por anunciar algunos paquetes de soluciones para el segmento de la pequeña y mediana empresa para México. En una primera fase, estos paquetes están a enfocados satisfacer necesidades puntuales a nivel de acceso a internet (archivo/impresón, web, proxy, etc.) y en una segunda fase serán complementados con paquetes para la parte de colaboración y correo/mensajería.

Publicado y extraido desde Pc Magazine

Introduciendonos en el mundo del .NET (2º Parte)

2005-10-10T21:48:44+00:00

Hoy definiremos un aspecto de vital importancia para el funcionamiento del .NET. El SOAP (Simple Object Access Protocol) es un protocolo estándar creado por Microsoft, IBM y otros, está actualmente bajo el auspicio de la W3C que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML.

SOAP es el protocolo de comunicaciones para los servicios XML Web Services. Cuando se describe SOAP como un protocolo de comunicaciones, muchas personas piensan en DCOM o CORBA y se preguntan "¿Cómo realiza SOAP la activación de objetos?" o "¿Qué servicio de nombres utiliza SOAP?" Mientras es posible que una implementación SOAP incluya estos datos, el estándar SOAP no los especifica. SOAP define el formato XML para mensajes. Si tiene un fragmento creado correctamente en XML e incluido en un par de elementos SOAP, dispondrá ya de un mensaje SOAP. Sencillo, ¿verdad? Existen otras partes en la especificación SOAP que describen cómo representar los datos de un programa como XML y cómo utilizar SOAP para realizar llamadas a procedimiento remoto (RPC). Estas partes opcionales de la especificación se utilizan para implementar aplicaciones estilo RPC en las que el cliente envía un mensaje SOAP que contiene una función a la que se puede llamar, además de los parámetros para pasar a la función. El servidor, por su parte, devuelve un mensaje con los resultados de la función ejecutada. Casi todas las implementaciones actuales de SOAP admiten aplicaciones RPC porque los programadores que trabajan con aplicaciones COM o CORBA conocen el estilo RPC. SOAP admite también aplicaciones con estilo de documento en las que los mensajes SOAP cubren un documento XML. Las aplicaciones SOAP con estilo de documento son muy flexibles. Muchos nuevos servicios XML Web Services aprovechan esta flexibilidad para diseñar servicios que sería difícil implementar mediante RPC. La última parte opcional de la especificación SOAP define los contenidos de un mensaje HTTP que contiene un mensaje SOAP. Este enlace HTTP es importante porque casi todos los sistemas operativos actuales, y otros no tan actuales, admiten HTTP. Este enlace es opcional pero casi todas las implementaciones SOAP lo admiten porque es el único protocolo estandarizado para SOAP. Por esta razón, existe la falsa idea general de que SOAP necesita HTTP. Algunas implementaciones admiten MSMQ, series MQ, SMTP o TCP/IP. Sin embargo, la mayoría de los servicios XML Web Services utilizan HTTP porque es ubicuo. Dado que HTTP es un protocolo imprescindible para el medio Web, muchas empresas disponen de infraestructuras de redes que lo admiten y personal con conocimientos y experiencia para gestionarlo. En la actualidad ya se encuentran disponibles la seguridad, el control y la infraestructura de equilibrio de cargas para HTTP. A la hora de empezar a trabajar con SOAP, es importante entender la diferencia entre la especificación SOAP y la variedad de implementaciones de esta especificación. Muchos programadores que utilizan SOAP no escriben mensajes SOAP directamente, sino que utilizan un SOAP Toolkit para crear y analizar mensajes SOAP. Generalmente, estos kits de herramientas traducen llamadas de función de algún tipo de lenguaje a un mensaje SOAP. Por ejemplo, Microsoft SOAP Toolkit 2.0 traduce llamadas de función COM a SOAP y el kit de herramientas de Apache traduce funciones de llamadas JAVA a SOAP. Los tipos de llamadas de función y los tipos de datos de los parámetros admitidos varían en cada implementación SOAP, de forma que es posible que una función que trabaja con un kit de herramientas no funcione con otro. Esto no es una limitación de SOAP, sino de la implementación específica que utilice en cada caso.La característica más notable de SOAP es que se ha implementado en diferentes plataformas de hardware y software, lo que significa que puede utilizarse para enlazar sistemas dispares dentro y fuera de su empresa. En el pasado se realizaron muchos intentos para conseguir un protocolo de comunicaciones común que pudiera usarse en la integración de sistemas. Sin embargo, ningún intento se ha generalizado tanto como SOAP. ¿Por qué? Porque SOAP es más pequeño y sencillo de implementar que muchos de los protocolos anteriores. Por ejemplo, se tardaron años en implementar DCE y CORBA, de modo que sólo unas pocas implementaciones llegaron a comercializarse. Por su parte, SOAP utiliza analizadores XML y bibliotecas HTTP existentes para realizar la mayor parte del trabajo más complicado; por ello, una implementación SOAP puede estar terminada en cuestión de meses. Ésta es la razón por la que hay disponibles más de 70 implementaciones SOAP. No obstante, SOAP no consigue los mismos resultados que DCE o CORBA pero su sencillez y características posibilitan que esté disponible rápidamente.La ubicuidad de HTTP y la sencillez de SOAP los convierte en una base perfecta para implementar servicios XML Web Services que pueden llamarse desde prácticamente cualquier entorno. Para obtener más información sobre SOAP, consulte la página principal de SOAP en MSDN.Aspectos sobre la seguridadUna de las primeras preguntas que se cuestiona un usuario nuevo es cómo protege SOAP la seguridad. En los primeros momentos de su desarrollo, SOAP era considerado como un protocolo basado en HTTP y, por tanto, se asumía que la seguridad de HTTP sería adecuada para SOAP. Además, existen miles de aplicaciones Web que se ejecutan actualmente utilizando la seguridad de HTTP. Por esta razón, el estándar SOAP actual supone que la seguridad es un problema de transporte y no comenta nada sobre los problemas de seguridad. La seguridad empezó a ser un problema en el momento en que SOAP se convirtió en un protocolo más generalizado que se ejecutaba en múltiples medios de transporte. Por ejemplo, HTTP proporciona diferentes modos de autenticar qué usuario realiza una llamada SOAP. Pero, ¿cómo se propaga esa identidad al dirigirse el mensaje desde HTTP a un transporte SMTP? SOAP se diseñó como un protocolo de base; afortunadamente existen especificaciones en los textos para diseñar en SOAP que proporcionan más características de seguridad para servicios Web. El artículo sobre la especificación WS-Security define sistemas de cifrado completos y el artículo WS-License define técnicas que protegen la identidad de la persona que llama y aseguran que sólo usuarios autorizados puedan utilizar un servicio Web.

Lo dejamos aca....saludos.

Introduciendonos en el mundo del .NET

2005-10-03T00:42:17+00:00

En esta serie de artículos nos iremos adentrando en el fascinante mundo del .NET

Introduccion a .NET

.NET es un proyecto de Microsoft para crear una nueva plataforma de desarrollo de software con énfasis en transparencia de redes, con independencia de plataforma y que permita un rápido desarrollo de aplicaciones. Basado en esta plataforma, Microsoft intenta desarrollar una estrategia horizontal que integre todos sus productos, desde el Sistema Operativo hasta las herramientas de mercadeo.

.NET podría considerarse una respuesta de Microsoft al creciente mercado de los negocios en entornos Web, como competencia a la plataforma Java de Sun Microsystems.

A largo plazo Microsoft pretende reemplazar la Interfaz de Programación de Aplicaciones (API por sus siglas en inglés) Win32 o Windows API con la plataforma .NET. Esto debido a que la API Win32 o Windows API fue desarrollada sobre la marcha, careciendo de documentación detallada, uniformidad y cohesión entre sus distintos componentes, provocando múltiples problemas en el desarrollo de aplicaciones para el sistema operativo Windows. La plataforma .NET pretende solventar la mayoría de estos problemas proveyendo un conjunto único y expandible con facilidad, de bloques interconectados, diseñados de forma uniforme y bien documentados, que permitan a los desarrolladores tener a mano todo lo que necesitan para producir aplicaciones sólidas.

Debido a las ventajas que la disponibilidad de una plataforma de este tipo puede darle a las empresas de tecnología y al público en general, muchas otras empresas e instituciones se han unido a Microsoft en el desarrollo y fortalecimiento de la plataforma .Net, ya sea por medio de la implementación de la plataforma para otros sistemas operativos aparte de Windows (Proyecto Mono de Ximian/Novell para Linux/MacOS X/BSD/Solaris), el desarrollo de lenguajes de programación adicionales para la plataforma (ANSI C de la Universidad de Princeton, NetCOBOL de Fujitsu, Delphi de Borland, entre otros) o la creación de bloques adicionales para la plataforma (como controles, componentes y librerías de clases adicionales); siendo algunas de ellas iniciativas de distribución gratuita bajo la licencia GNU.

Con esta plataforma Microsoft incursiona de lleno en el campo de los Servicios Web y establece el XML como norma en el transporte de información en sus productos y lo promociona como tal en los sistemas desarrollados utilizando sus herramientas.

.NET intenta ofrecer una manera rápida y económica pero a la vez segura y robusta de desarrollar aplicaciones - o como la misma plataforma las denomina, soluciones - permitiéndo a su vez una integración más rápida y ágil entre empresas y un acceso más simple y universal a todo tipo de información desde cualquier tipo de dispositivo.

Lo dejamos aca....

Fuentes : Wikipedia & Microsoft

Conceptos de programacion en .NET

2005-09-26T16:56:02+00:00

Conoceremos las distintas versiones de Visual Studio .NET y los requisitos de instalación; comentaremos algunos trucos y finalmente instalaremos paso a paso Visual Studio .NET.En esta sección veremos conceptos básicos de programación utilizando Visual Studio .NET y ASP .NET Web Matrix.3.2.1.
Programación Orientada a Eventos, Formularios y Controles.
En esta sección veremos el concepto de programación orientada a eventos; cómo crear formularios y controles.3.2.1.1. Objetos, Métodos, Propiedades y Eventos.Para escribir aplicaciones en Visual Studio .NET o en Web Matrix usted va a trabajar con objetos, métodos, propiedades y eventos. Definamos estos conceptos:
Objetos:Son los ladrillos de construcción de las aplicaciones de Visual Basic.Son los elementos programables que usted utiliza para hacer su aplicación.Para poder interactuar con los objetos usted utiliza las propiedades, métodos y eventos.Para entender mejor estos conceptos vamos a hacer una analogía entre un objeto físico, un reloj despertador, un objeto de Visual Basic .NET, y un formulario.
Propiedades: Las propiedades son las caractersticas de un objeto.Por ejemplo, las propiedades de un reloj despertador pueden ser su altura, ancho y color. Un formulario en Visual Basic también tiene sus propiedades como por ejemplo, altura, ancho y color.
Métodos: Los métodos son las cosas que los objetos pueden hacer.Por ejemplo, con un reloj despertador usted podrá modificar la hora y modificar los minutos. Los métodos de los formularios son las cosas que éstos pueden hacer tales como mostrarse y ocultarse.
Eventos: Los eventos son las acciones a las que un objeto puede responder.Por ejemplo, el reloj despertador puede responder al evento de alarma emitiendo sonidos. Cuando un usuario cierra un formulario, el formulario responde a un evento llamado closed que ejecuta el código que el programador puso en el evento.
¿Qué es la programación manejada por eventos?
Las aplicaciones en Visual Studio .NET y Web Matrix son manejadas por Eventos. Hay otros paradigmas de programación, uno de ellos es la programación procedural.
Programación Procedural: En este modelo el programa principal controla el flujo lógico de ejecución de un programa, por ejemplo, la manera en que la información es ingresada por el usuario.
Programación Manejada por Eventos: El usuario genera eventos como mover el mouse o presionar una tecla y esto provoca la ejecución del segmento de código asociado al evento. Por ejemplo, como se puede ver en la imagen, cuando un usuario hace clic en el botón del formulario se ejecuta el código que el programador de la aplicación haya puesto. Es decir, depende de la acción del usuario la ejecución de ese código.
Clases: Las Plantillas de los Objetos.
Clase: De la misma manera que el plano de una casa describe los elementos que hacen la casa como ventanas o puertas, una clase es una representacin simbólica de objetos. Una clase define las propiedades y operaciones que cualquier miembro de ella deber tener.
Objeto: Es una instancia de una clase. Usted utiliza una clase para crear los objetos que necesite. De la misma manera que se usa un plano para construir una casa.
Ejemplos:Cada formulario que usted usa en una aplicación de Visual Studio .NET o Web Matrix es un objeto. La clase a partir de la cual se generó el formulario es la clase Form.Cada control que usted pone en un formulario es un objeto. La clase de la cual deriva se llama clase Control.
Clases: Describen las propiedades, métodos y eventos de los objetos que son miembros de ella.Propiedades: Son las características de un objeto como por ejemplo su tamaño, color o forma.Métodos: Son la acciones que un objeto puede hacer. En el caso de un formulario, por ejemplo, Cerrar y Ocultar.Eventos: Son las acciones que un objeto reconoce y como resultado de ello ejecuta código asociado. Por ejemplo, un control en un formulario que reconoce que el usuario hizo clic sobre él y por lo tanto cierra la ventana.De la misma manera que usted puede usar los componentes de una radio, por ejemplo el volumen, sin necesidad de saber cómo son los circuitos electrónicos; en un programa los objetos son usados y el programador no necesita saber cómo fue escrito el código.Por ejemplo, usted pone en un formulario un control, escribe código en el evento clic y ejecuta el programa. Durante la ejecución al hacer clic en el control, el control responde al evento clic y ejecuta el código asociado. Usted esta usando un objeto pero no necesita saber cómo está escrito. La clase control fue escrita por Microsoft y usted la utiliza para crear objetos de tipo control.Esto es muy importante. Convierte a los objetos en cajas negras donde lo que interesa es lo que hace y no cómo está implementado. Es decir, se encapsula la complejidad y además permite la reusabilidad del código ya que usted no tiene que volver a escribir el código del objeto cada vez que lo utiliza. ¡Imagine si usted tuviera que conocer cómo trabaja cada función del sistema operativo y tuviera que escribir el código cada vez para poder hacer alguna operación!

Lo dejamos aca....chau...

Las mejores herramientas para comprimir

2005-09-05T18:02:41+00:00

He aqui las mejores aplicaciones para comprimir tus archivos.

Winzip es una aplicacion que ha demostrado tener una gran eficacia en los distintos metodos de compresion, y todas con una velocidad muy alta. Sus principales ventajas son la alta eficacia y velocidad, como su modo guiado para comprimir archivos. Su principal contra es que solo trabaja con archivos ZIP y ZIP codificados.
Su pagina es www.winzip.com
----------------------------------------------------

WinRar es uno de los programas mas famosos para la compresion de datos. Es una aplicacion muy utilizada que se centra en otro formato estandar de compresion como lo es el RAR. Sin embargo, a excepcion de su nombre, es compatible con ZIP y otros formatos menos habituales. Incluso puede trabajar con imagenes de CD y/o DVD que utilicen el estandar ISO. Sus principales ventajas son su interfaz personalible, su rapidez y sencillez, su contra es que al igual que WinZip es una aplicacion por que la que hay que pagar.
Su pagina es www.rarlab.com
-----------------------------------------------------

Este es una aplicacion gratuita que puede dar grandes resultados si no quere optar por una alternativa de pago. Lee los formatos mas habituales, RAR, ZIP, ARJ. Trae integrado un FTP que te permitira subir tus archivos a tu sitio.
Lo mejor es su soporte multiformato y su perfomance en general es buena, sin embargo, esta compuesto de muchas aplicaciones independientes que hacen un tanto dificil la utilizacion de este programa.
Su pagina es www.zipgenius.it

Lo dejo aca.....chau