En computación distribuida, GIOP (Protocolo Entre ORBs General, General Inter-ORB Protocol) es el protocolo abstracto por el cual los ORBs se comunican. Los estándares asociados con el protocolo son mantenidos por el Object Management Group (OMG).

IIOP (Internet Inter-Orb Protocol) es la implementación de GIOP para TCP/IP. Es una realización concreta de las definiciones abstractas de GIOP.

El Object Management Group define tres partes en GIOP:

• La Representación Común de Datos (CDR) - es una sintaxis de transferencia, que mapea los tipos de datos de IDL en una representación de bajo nivel para su transferencia "por el hilo" entre ORBs.
• La Referencia de Objetos Interoperable (IOR) -define el formato de una referencia a un objeto remoto. Una IOR consiste en varios perfiles etiquetados, y sus componentes pueden llevar diversa información según se necesite. La IOR típica habitualmente contiene la versión del protocolo, la dirección del servidor y una secuencia de octetos que identifica al objeto remoto (clave del objeto).

• Los formatos de mensaje definidos - los mensajes se intercambian entre agentes para facilitar las peticiones de objetos, localizar implementaciones de objetos y gestionar los canales de comunicación. Los mensajes posibles son:

• • Request se envía con el propósito de invocar el método remoto
  • Reply se devuelven como respuesta del Request. Por lo general contiene los datos devueltos por el método remoto. En otros casos o la descripción de la excepción que fue lanzada en el lado del servidor.
  • CancelRequest se utiliza para cancelar una petición que había sido enviada (ya no se espera una respuesta)
  • LocateRequest se utiliza para verificar si el servidor conoce y soporta cierto objeto remoto, y en caso contrario, a qué dirección deberían enviarse las peticiones a ese objeto.
  • LocateReply se envía desde el servidor como respuesta a LocateRequest. Si es necesario, puede contener la nueva dirección del objeto remoto que se ha movido.
  • CloseConnection es enviado por el servidor cuando desea indicar que no proporcionará más respuestas en un futuro.
  • MessageError se envía como respuesat a mensajes no válidos o mal formados. No se utiliza para informar de errores más allá del sistema de mensajes; tales errores deben enviarse usando el mensaje Reply.
  • Fragment es un mensaje posterior, que es continuación del mensaje previo.

En los volcados binarios, el mensaje GIOP puede reconocerse fácilmente por su cabecera característica:

1. Cuatro caracteres ASCII: G I O P
2. Los dos bytes, que definen los números mayor (en la actualidad el 1) y menor de versión.
3. Un octeto, que define los flags del mensaje. El bit menos significativo define el orden de bytes (0 - big endian, 1 - little endian).
4. Un octeto que define el tipo de objeto (Reply, Request, Fragment, etc.)
5. Una palabra de cuatro octetos que define el tamaño del mensaje (sin contar la cabecera)

Estos mensajes también pueden transportar fragmentos arbitrarios e datos. Estos fragmentos adicionales de datos se llaman contextos de servicio y se utilizan para extender la comunicación estándar cuando se necesita. Existen contextos de servicio estándar para describir la excepción lanzada, para especificar el juego de caracteres, etc. Es posible registrar interceptadores en el lado del cliente y del servicio para añadir contextos de servicio especfícos a los mensajes que se envían, así como leer los dichos contextos, añadidos por el interceptor en el lado remoto.

CORBA, IIOP y OMG son marcas registradas del Object Management Group y deben ser usadas con cuidado. Sin embargo, GIOP no es marca registrada por el OMG (véase listado de marcas del OMG). Por tanto en ciertos casos es más apropiado simplemente decir que la aplicación utiliza o implemente una arquitectura basada en GIOP.

• ESIOP
• HTIOP
• XIOP

• El estándar oficial CORBA y GIOP (unos 10 MB)
• Formalización y validación del protocolo GIOP utilizando Promela y SPIN