|
Dieses Gerät hat auch andere Anweisungen:
Anleitung Zusammenfassung
The NonStop CORBA ORB
The NonStop CORBA ORB, although conceptually a single entity, is actually a group of mechanisms. Among these are an
SRL (Shared Runtime Library), databases, and the stubs and skeletons representing CORBA objects. The SRL contains
mechanisms, which control all events, threads, database I/O, and the interaction the ORB requires to act as the object
message bus, to assure delivery and proper system interaction.
The stubs and skeletons contain the required code to marshal and demarshal the actual requests and their parameters.
GIOP and IIOP
Inter-ORB communications are accomplished through a standard, the Generalized Inter-ORB Protocol (GIOP). There are
several versions of the protocol, and NonStop CORBA supports GIOP 1.0, 1.1, and 1.2. One variation of GIOP is the Internet
Inter-ORB Protocol (IIOP). IIOP uses GIOP messages over the TCP/IP transport mechanism. The OMG defines a set of data
formatting rules, called CDR (Common Data Representation), which is tailored to the data types supported in the CORBA
Interface Definition Language (IDL). Using the CDR data formatting rules, the specification also defines a set of message
types that support all of the ORB semantics. Together, the CDR formatting rules and the message formats constitute an
abstract protocol called GIOP. GIOP messages can be sent over virtually any data transport protocol, such as TCP/IP, the
TS/MP Pathsend interface, the NonStop server file system, and many others. To ensure out-of-the-box interoperability
between ORB products, the IIOP specification requires that ORBs send GIOP messages over TCP/IP connections because
TCP/IP is the standard connection-oriented transport protocol for the Internet. To put it very simply, GIOP + TCP/IP = IIOP.
Objects publish their identities and locations in the form of object references. CORBA specifications dictate a common
format for object references exchanged over IIOP, called the IOR (Interoperable Object Reference) format. An IOR contains
one or more profiles. Each profile describes how a client object can contact and send requests to the object using a particular
protocol. For interoperability between ORBs provided by different vendors, an IOR should contain an IIOP profile to ensure
that wherever that reference goes, any CORBA ORB can locate the object and send requests to it. The IIOP profile contains
the Internet address of the objects server and a key value used by the server to find the specific object described by the
reference.
Object references can be converted into character strings, which can be published arbitrarily, like URLs, in e-mail messages,
files, databases, directories, and so on. Any CORBA application can convert the string into an IOR and use it to locate and
invoke the object. Alternatively, the IOR can be obtained from the Naming Service.
When a client program built with one ORB vendors product needs to talk to an object in a server built with another ORB
vendors product, the client program opens a TCP/IP connection to the server and sends one or more IIOP requests to the
server. The ORB component linked into the server locates or activates the object specified in the request and invokes the
appropriate method on the object. The fact that the object is not built with the same ORB product is invisible to the client.
CORBA/IIOP is platform-independent. CORBA ORBs interoperate without regard to vendor origin, making CORBA/IIOP
the truly ideal solution for the Internet.
NonStop CORBA 2.6 can use three transport protocols when communicating between objects. All three use GIOP and each
can be represented as a profile within an IOR. These three protocols are:
IIOP, the standard messaging protocol utilizing TCP/IP, used for all remote messages to platforms other than NonStop
q
server platforms.
GIOP over TS/MP inter-ORB protocol implementation. This protocol is used when accessing objects whose server is
q
controlled by TS/MP.
GIOP over Guardian file system inter-ORB protocol Implementation). This protocol is used when client objects wish
q
to communicate with objects whose server is either running as a stand-alone process or as stateful objects managed by
TS/MP.
The tools for configuring these protocols are described later in this manual.
...Dieses Handbuch ist für folgende Modelle:
PC Desktops - HP NonStop L-Series (614.61 kb)