jueves, 4 de septiembre de 2008

PROSOFT

¿Qué es PROSOFT?

Estímulos y financiamiento
Estimulos fiscales
FinanciamientoPrograma del gobierno federal para detonar la industria de software y servicios de TI con una visión a 10 años. La industria de software ha sido identificada como sector prioritario para el gobierno federal mexicano. Para detonar esta industria el sector privado, académico y público definieron el programa para desarrollar la industria de software "PROSOFT".
Objetivo del Programa
El Fondo del Programa para el Desarrollo de la Industria del Software (PROSOFT) tiene como objetivo impulsar el desarrollo de la industria de las tecnologías de información a través del otorgamiento de subsidios de carácter temporal a proyectos que estén dirigidos a la creación, desarrollo, consolidación, viabilidad, productividad, competitividad y sustentabilidad de las empresas del sector de Tecnologías de Información y servicios relacionados.
Población Objetivo
El PROSOFT tiene cobertura nacional y su población objetivo, definida en el artículo 3, es sujeta de ser beneficiaria para obtener apoyos para la realización de los proyectos que se describen en las presentes Reglas de Operación.
Ver información detallada
Requisitos de Acceso
Serán elegibles para acceder a los apoyos del PROSOFT, sin distinción de género, raza, credo, condición socioeconómica o cualquier otra causa que implique discriminación, la población objetivo establecida en los artículos 3 y 12 de las presentes Reglas de Operación, que reúna los requisitos siguientes:
I. Que estén legalmente constituidos conforme a la legislación mexicana;
II. Que el proyecto para el que soliciten apoyo, cumpla con las características establecidas en las presentes Reglas de Operación;
III. Que soliciten apoyos por proyecto, sin rebasar los montos y porcentajes máximos establecidos para cada tipo de proyecto , pudiendo solicitar más de uno de ellos, conforme a lo señalado en el artículo 22 y el Anexo A, sin perjuicio de la posibilidad establecida en el artículo 20 de las presentes Reglas de Operación;
IV. Que los proyectos cumplan con los criterios de elegibilidad aplicables a que se refiere el artículo 15 de las presentes Reglas de Operación,
V. Que cuente con su registro en el Directorio de Empresas de TI (DETI) de la SE, a través de la página www.software.net.mx, y
VI. Que no estén recibiendo apoyos de otros programas federales para el mismo concepto, que impliquen sustituir su aportación o duplicar apoyos o subsidios conforme a lo establecido en las presentes Reglas de Operación.
La Dirección General de Comercio Interior y Economía Digital verificará que los Beneficiarios de ejercicios anteriores de este u otros fondos o programas de la SE estén al corriente con las obligaciones a su cargo para que nuevamente sean elegibles de apoyo en el presente ejercicio fiscal. Bajo ningún concepto podrán ser Beneficiarios del PROSOFT los servidores públicos de la SSIC, de las Delegaciones o en general de la SE, de las Secretarías de Desarrollo Económico o su equivalente de las Entidades Federativas, así como sus cónyuges o parientes consanguíneos y las demás personas que al efecto se refieran en las legislaciones federal y estatales aplicables en materia de responsabilidades de los servidores públicos.

PROSOFT

¿Qué es PROSOFT?


Estímulos y financiamiento Estimulos fiscales Financiamiento.

Programa del gobierno federal para detonar la industria de software y servicios de TI con una visión a 10 años. La industria de software ha sido identificada como sector prioritario para el gobierno federal mexicano. Para detonar esta industria el sector privado, académico y público definieron el programa para desarrollar la industria de software "PROSOFT".
Objetivo del Programa
El Fondo del Programa para el Desarrollo de la Industria del Software (PROSOFT) tiene como objetivo impulsar el desarrollo de la industria de las tecnologías de información a través del otorgamiento de subsidios de carácter temporal a proyectos que estén dirigidos a la creación, desarrollo, consolidación, viabilidad, productividad, competitividad y sustentabilidad de las empresas del sector de Tecnologías de Información y servicios relacionados.
Población Objetivo
El PROSOFT tiene cobertura nacional y su población objetivo, definida en el artículo 3, es sujeta de ser beneficiaria para obtener apoyos para la realización de los proyectos que se describen en las presentes Reglas de Operación.
Ver información detallada
Requisitos de Acceso
Serán elegibles para acceder a los apoyos del PROSOFT, sin distinción de género, raza, credo, condición socioeconómica o cualquier otra causa que implique discriminación, la población objetivo establecida en los artículos 3 y 12 de las presentes Reglas de Operación, que reúna los requisitos siguientes:
I. Que estén legalmente constituidos conforme a la legislación mexicana;
II. Que el proyecto para el que soliciten apoyo, cumpla con las características establecidas en las presentes Reglas de Operación;
III. Que soliciten apoyos por proyecto, sin rebasar los montos y porcentajes máximos establecidos para cada tipo de proyecto , pudiendo solicitar más de uno de ellos, conforme a lo señalado en el artículo 22 y el Anexo A, sin perjuicio de la posibilidad establecida en el artículo 20 de las presentes Reglas de Operación;
IV. Que los proyectos cumplan con los criterios de elegibilidad aplicables a que se refiere el artículo 15 de las presentes Reglas de Operación,
V. Que cuente con su registro en el Directorio de Empresas de TI (DETI) de la SE, a través de la página www.software.net.mx, y
VI. Que no estén recibiendo apoyos de otros programas federales para el mismo concepto, que impliquen sustituir su aportación o duplicar apoyos o subsidios conforme a lo establecido en las presentes Reglas de Operación.
La Dirección General de Comercio Interior y Economía Digital verificará que los Beneficiarios de ejercicios anteriores de este u otros fondos o programas de la SE estén al corriente con las obligaciones a su cargo para que nuevamente sean elegibles de apoyo en el presente ejercicio fiscal. Bajo ningún concepto podrán ser Beneficiarios del PROSOFT los servidores públicos de la SSIC, de las Delegaciones o en general de la SE, de las Secretarías de Desarrollo Económico o su equivalente de las Entidades Federativas, así como sus cónyuges o parientes consanguíneos y las demás personas que al efecto se refieran en las legislaciones federal y estatales aplicables en materia de responsabilidades de los servidores públicos.
Presentación del taller PROSOFT 2007
Descargar presentación
Documentos y Formatos de apoyo - Recepción de proyectos a partir de Febrero 1 al 30 de Abril
Proyecto en extenso - 2008
Carta Compromiso - 2008
Anexo A
Anexo B - Ejemplo de llenado de Anexo B
Reglas de operación - 2008
Relación de cotizaciones - 2008
Ley de adquisiciones - 2008
Carta de entrega de proyectos
Organismos Promotores
Los apoyos del PROSOFT están integrados por subsidios y se otorgan a los Beneficiarios a través de los Organismos Promotores del PROSOFT, ya sean Entidades Federativas y/o Organismos Empresariales del sector de TI con apego a las disposiciones de las Reglas de Operación del Fondo PROSOFT.

BASE DE DATOS MASTER

BASE DE DATOS MASTER
La base de datos master registra toda la información de sistema de un sistema SQL Server. Dentro de esta información se incluyen los metadatos de todas las instancias, como las cuentas de inicio de sesión, los extremos, los servidores vinculados y la configuración del sistema. Asimismo, master es la base de datos que registra la existencia de las demás bases de datos, la ubicación de los archivos de las bases de datos y la información de inicialización de SQL Server. Por lo tanto, SQL Server no puede iniciarse si la base de datos master no está disponible. En SQL Server, los objetos de sistema ya no se almacenan en la base de datos maestra, sino en la base de datos de recursos.
Propiedades físicas de la base de datos maestra

En la siguiente tabla se enumeran los valores de configuración iniciales de los archivos de registro y datos de master. El tamaño de estos archivos puede variar ligeramente para cada edición de SQL Server.
Restricciones

Las siguientes operaciones no se pueden realizar en la base de datos master:
Agregar archivos o grupos de archivos.
Cambiar intercalaciones. La intercalación predeterminada es la intercalación de servidor.
Cambiar el propietario de la base de datos. El propietario de master es dbo.
Crear un catálogo de texto o un índice de texto.
Crear desencadenadores en las tablas del sistema de la base de datos.
Eliminar la base de datos.
Eliminar el usuario guest de la base de datos.
Habilitar el mecanismo de captura de cambios en los datos.
Participar en el reflejo de la base de datos.
Quitar el grupo de archivos principal, el archivo de datos principal o el archivo de registro.
Cambiar el nombre de la base de datos o del grupo de archivos principal.
Establecer la base de datos en OFFLINE.
Establecer la base de datos o el grupo de archivos principal en READ_ONLY.

CONCURRENCIA EN LAS BASES DE DATOS

CONTROL DE CONCURRENCIA EN BASES DE DATOS

El control de transacciones concurrentes en una base de datos brinda un eficiente desempeño del Sistema de Base de Datos, puesto que permite controlar la ejecución de transacciones que operan en paralelo, accesando a información compartida y, por lo tanto, interfiriendo potencialmente unas con otras.
El hecho de reservar un asiento en una avión mediante un sistema basado en aplicaciones
web, cuando decenas de personas en el mundo pueden reservarlo también, nos da una idea de lo importante y crucial que es el control de concurrencia en un sistema de base de datos a mediana o gran escala.
Otro ejemplo en el que podemos observar la incidencia del control de concurrencia en el siguiente: en una Base de Datos bancaria podría ocurrir que se paguen dos
cheques en forma simultánea sobre una cuenta que no tiene saldo suficiente para cubrirlos en su totalidad, esto es posible evitarlo si se tiene un control de concurrencia.
2. TRANSACCIONES
Los
sistemas que tratan el problema de control de concurrencia permiten que sus usuarios asuman que cada una de sus aplicaciones se ejecutan atómicamente, como si no existieran otras aplicaciones ejecutándose concurrentemente.
Esta abstracción de una ejecución atómica y confiable de una aplicación se conoce como una transacción.
Un
algoritmo de control de concurrencia asegura que las transacciones se ejecuten atómicamente controlando la intercalación de transacciones concurrentes, para dar la ilusión de que las transacciones se ejecutan serialmente, una después de la otra, sin ninguna intercalación. Las ejecuciones intercaladas cuyos efectos son los mismos que las ejecuciones seriales son denominadas serializables y son correctos ya que soportan la ilusión de la atomicidad de las transacciones.
El
concepto principal es el de transacción. Informalmente, una transacción es la ejecución de ciertas instrucciones que accesan a una base de datos compartida. El objetivo del control de concurrencia y recuperación es asegurar que dichas transacciones se ejecuten atómicamente, es decir:
Cada transacción accede a información compartida sin interferir con otras transacciones, y si una transacción termina normalmente, todos sus efectos son permanentes, en caso contrario no tiene afecto alguno.
Una base de datos está en un
estado consistente si obedece todas las restricciones de integridad (significa que cuando un registro en una tabla haga referencia a un registro en otra tabla, el registro correspondientes debe existir) definidas sobre ella.
Los cambios de estado ocurren debido a actualizaciones, inserciones y supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entre en un estado de inconsistencia.
Sin embargo, durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente
.

COMO FUNCIONA EL ESQUEMA DE DOBLE PAGINACION.

Técnicas de doble paginación

Alternativa a las técnicas de recuperación de caídas basadas en diarios.
El sistema mantiene dos tablas de paginación durante la vida de una transacción, y son idénticas al comenzar la transacción.

– Tabla de paginación actual
» Puede variar cuando la transacción realiza una operación write. Todas las operaciones input y output utilizan esta tabla para localizar las páginas de la BD.
Puede almacenarse en memoria volátil.

– Tabla de paginación doble
» No se modifica, y debe almacenarse en memoria no volátil.

Commitment con doble paginación

1. Comprobar que todas las páginas del buffer que haya modificado la transacción se graban en disco.
2. Grabar en disco la tabla de paginación actual.
3. Grabar la dirección en disco de la tabla de paginación actual en la posición fija de memoria estable que contenga la dirección de la tabla de paginación doble. Por tanto, la tabla de paginación actual se convierte en la tabla de paginación doble y la transacción está cometida.

Ventajas y desventajas de doble paginación

Ventajas frente a los diarios :

– No es necesario aplicar ningún procedimiento de recuperación
– Se elimina el tiempo para grabar registros.
– La recuperación de las caídas es más rápida.

Desventajas:

– Fragmentación de los datos.
– Recolección de basura.
– La doble paginación es más difícil de adaptar que un diario a los sistemas que permiten ejecución concurrente de transacciones.

lunes, 1 de septiembre de 2008

OLTP

OLTP.

OLTP es la sigla en inglés de Procesamiento de Transacciones En Línea (OnLine Transaction Processing) es un tipo de sistemas que facilitan y administran aplicaciones transaccionales, usualmente para entrada de datos y recuperación y procesamiento de transacciones (gestor transaccional). Los paquetes de software para OLTP se basan en la arquitectura cliente-servidor ya que suelen ser utilizados por empresas con una red informática distribuida.
El término puede parecer ambiguo, ya que puede entenderse "transacción" en el contexto de las "transacciones computacionales" o de las "
transacciones en bases de datos". También podría entenderse en términos de transacciones de negocios o comerciales. OLTP también se ha utilizado para referirse a la transformación en la que el sistema responde de inmediato a las peticiones del usuario. Un Cajero automático de un banco es un ejemplo de una aplicación de procesamiento de transacciones comerciales.
La tecnología OLTP se utiliza en innumerables aplicaciones, como en
banca electrónica, procesamiento de pedidos, comercio electrónico, supermercados o industria.

Beneficios.

El procesamiento de transacciones en linea tiene dos claros beneficios: la simplicidad y la eficiencia.
Sobre la simplicidad:
La reducción de la documentación y la obtención de previsiones de ingresos y gastos de forma más rápida y precisa son ejemplos de cómo OLTP hace las cosas más simples para las empresas.
También proporciona una base concreta para la estabilidad de una organización gracias a las actualizaciones oportunas.
Otro factor es que la simplicidad de permitir a los consumidores la elección de la forma en que desean pagar, por lo que es mucho más atractivo que la de hacer transacciones.
Sobre la eficiencia:
OLTP amplía la base de consumidores para una organización.
Los procesos individuales se ejecutan mucho más rápido.

WEB SERVICE.

Web service.
Un servicio web (en inglés Web service) es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares.
Estándares empleados.

Web Services Protocol Stack: Así se denomina al conjunto de servicios y protocolos de los servicios Web.
XML (Extensible Markup Language): Es el formato estándar para los datos que se vayan a intercambiar.
SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call): Protocolos sobre los que se establece el intercambio.
Otros protocolos: los datos en XML también pueden enviarse de una aplicación a otra mediante protocolos normales como
HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), o SMTP (Simple Mail Transfer Protocol).
WSDL (Web Services Description Languages): Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web.
UDDI (Universal Description, Discovery and Integration): Protocolo para publicar la información de los servicios Web. Permite comprobar qué servicios web están disponibles.
WS-Security (Web Service Security): Protocolo de seguridad aceptado como estándar por OASIS (Organization for the Advancement of Structured Information Standards). Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados...
Ventajas de los servicios Web.

Aportan interoperabilidad entre aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen.
Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento.
Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los sistemas de seguridad
firewall sin necesidad de cambiar las reglas de filtrado.
Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados.
Permiten la interoperabilidad entre plataformas de distintos fabricantes por medio de protocolos estándar y abiertos. Las especificaciones son gestionadas por una organización abierta, la
W3C, por tanto no hay secretismos por intereses particulares de fabricantes concretos y se garantiza la plena interoperabilidad entre aplicaciones.


Inconvenientes de los servicios Web.
Para realizar transacciones no pueden compararse en su grado de desarrollo con los estándares abiertos de computación distribuida como CORBA (Common Object Request Broker Architecture).
Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como
RMI (Remote Method Invocation), CORBA, o DCOM (Distributed Component Object Model). Es uno de los inconvenientes derivados de adoptar un formato basado en texto. Y es que entre los objetivos de XML no se encuentra la concisión ni la eficacia de procesamiento.
Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en
firewall cuyas reglas tratan de bloquear o auditar la comunicación entre programas a ambos lados de la barrera.

Razones para crear servicios Web.

La principal razón para usar servicios Web es que se basan en HTTP sobre TCP (Transmission Control Protocol) en el puerto 80. Dado que las organizaciones protegen sus redes mediante firewalls -que filtran y bloquean gran parte del tráfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web utilizan este puerto, por la simple razón de que no resultan bloqueados.
Otra razón es que, antes de que existiera
SOAP, no había buenas interfaces para acceder a las funcionalidades de otros ordenadores en red. Las que había eran ad hoc y poco conocidas, tales como EDI (Electronic Data Interchange), RPC, u otras APIs (Application Programming Interface).
Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada.
Se espera que para los próximos años mejoren la calidad y cantidad de servicios ofrecidos basados en los nuevos estándares.Razones para crear servicios Web [
editar]
La principal razón para usar servicios Web es que se basan en
HTTP sobre TCP (Transmission Control Protocol) en el puerto 80. Dado que las organizaciones protegen sus redes mediante firewalls -que filtran y bloquean gran parte del tráfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web utilizan este puerto, por la simple razón de que no resultan bloqueados.
Otra razón es que, antes de que existiera
SOAP, no había buenas interfaces para acceder a las funcionalidades de otros ordenadores en red. Las que había eran ad hoc y poco conocidas, tales como EDI (Electronic Data Interchange), RPC, u otras APIs (Application Programming Interface).
Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada.
Se espera que para los próximos años mejoren la calidad y cantidad de servicios ofrecidos basados en los nuevos estándares.

CORBA

CORBA.


En computación, CORBA (Common Object Request Broker Architecture — arquitectura común de intermediarios en peticiones a objetos), es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos.
CORBA fue definido y está controlado por el
Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, lo que es fundamental en computación distribuida.
En un sentido general CORBA "envuelve" el código escrito en otro lenguaje en un paquete que contiene información adicional sobre las capacidades del código que contiene, y sobre cómo llamar a sus métodos. Los objetos que resultan pueden entonces ser invocados desde otro
programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras pero con más información.
CORBA utiliza un lenguaje de definición de interfaces (
IDL) para especificar los interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java y Python. Hay también implementaciones para Perl y TCL.
Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware.

martes, 26 de agosto de 2008

TAREA DE ODBC

ODBC (Open Data Base Conectivity).

O lo que es lo mismo, conectividad abierta de bases de datos. Si escribimos una aplicación para acceder a las tablas de una DB de Access, ¿qué ocurrirá si después queremos que la misma aplicación, y sin reescribir nada, utilice tablas de SQL Server u otra DB cualquiera? La respuesta es sencilla: no funcionará. Nuestra aplicación, diseñada para un motor concreto, no sabrá dialogar con el otro. Evidentemente, si todas las DB funcionaran igual, no tendríamos este problema.... aunque eso no es probable que ocurra nunca.
Pero si hubiera un elemento que por un lado sea siempre igual, y por el otro sea capaz de dialogar con una DB concreta, solo tendríamos que ir cambiando este elemento, y nuestra aplicación siempre funcionaría sin importar lo que hay al otro lado... algo así como ir cambiando las boquillas de una manguera. A esas piezas intercambiables las llamaremos orígenes de datos de ODBC
Casi todas las DB actuales tienen un ODBC. Debido a que este elemento impone ciertas limitaciones, ya que no todo lo que la DB sabe hacer es compatible con la aplicación, como velocidad de proceso, tiempos de espera, máxima longitud de registro, número máximo de registros, versión de SQL, etc., está cayendo en desuso a cambio de otras técnicas de programación, pero aún le quedan muchos años de buen servicio.
Todo lo referido aquí funciona con Windows NT Server 4.0 con el Service Pack 4 o superior instalado (el último publicado es el 6). El Option Pack 4 para actualizar el IIS y las extensiones ASP. SQL Server 6.5 y Access 97. Por supuesto, también funciona con las versiones modernas de servidores como 2003 Server, y también XP PRO, que lleva un IIS 5.0 de serie. Igualmente es posible utilizar bases de datos de Access 2000 o 2003.
Esas otras técnicas de programación antes mencionadas, se utilizan ya en el nuevo Windows 2003, Office 2003 y SQL Server 2000, que además de ODBC pueden utilizar.... pero esa es otra historia.
Esta es la idea: por un lado el ODBC provee de unas caracteríisticas siempre homogéneas, y por el otro permite distintos controladores que aseguran la conectividad de la aplicación con diferentes bases de datos.
Ahora que ya sabemos qué es y para lo que sirve, procedamos a su instalación: es un proceso sencillo, pero según la base de datos elegida sea Access o SQL Server, cambian un poco, y como no podía ser menos, hay algunos trucos que conviene conocer.

TAREA RPC

RPC.
El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.
Las RPC son muy utilizadas dentro del
paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente.
Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado
ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM. Ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor.
Hoy en día se está utilizando el
XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de éstos pueden ser SOAP o XML-RPC.