IBM E02HMLL-I Implementation Guide - Page 28

Communication, transport, infrastructure, CORBA

Page 28 highlights

Within a data map, the conversion of source to destination attributes can be simple, or it can require establishing and maintaining relationships between data entities that are equivalent but which are represented differently in each different application, and so cannot be directly transformed. For example, for a Country attribute, one application might use a two-letter code (such as US, FR, or EG) while another application uses a numeral (such as 1, 2, or 3). To associate such attributes between different applications, you create a relationship definition, associating the data of the source and destination attributes. Most maps use one or more relationship definitions. Both map and relationship definitions reside in the repository of InterChange Server Express. Like business object definitions, relationship definitions function as specifications or templates for the instances that are created. Unlike instances of business objects, relationship instances persist, and are stored in special tables for each relationship. Each time the system receives a request to transform a given business object, it executes the associated map, and, depending upon the purpose of the transformation, creates one or more instances of its associated relationship definitions. Relationship instances created during map execution contain the runtime data from the attributes they associate, and this data is stored in relationship tables. Communication transport infrastructure Administrative interactions between distributed InterChange Server Express components are enabled by the Common Object Request Broker Architecture (CORBA). Content data transfers--that is, the business data that is being exchanged--can utilize either CORBA, or messaging technology provided by the Java Messaging Service (JMS) using WebSphere MQ queues. CORBA The Common Object Request Broker Architecture (CORBA) defines a set of standards and interfaces for distributed objects on a network. The Object Request Broker (ORB) is a set of libraries and other components that client applications and object servers use to communicate. InterChange Server Express uses the IBM Java ORB product. The ORB makes InterChange Server Express accessible to its clients, the connector agent, and System Manager. An InterChange Server ExpressExpress instance registers with the ORB's name service, from which a client obtains the information it needs to find and start interacting with the server. The client and server perform object-to-object interactions by means of the ORB's Interface Definition Language (IDL). At a transport level, they communicate by means of the Internet Inter-ORB Protocol (IIOP). ORB-based communication is typically used for the following purposes: v The Server Access Interface uses ORB-based communication to handle calls. v Optionally, in request/response interactions, collaborations and connectors use ORB-based communication to exchange business objects. v A connector agent uses ORB-based communication: 16 IBM WebSphere Business Integration Server Express and Express Plus: System Implementation Guide

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302

Within
a
data
map,
the
conversion
of
source
to
destination
attributes
can
be
simple,
or
it
can
require
establishing
and
maintaining
relationships
between
data
entities
that
are
equivalent
but
which
are
represented
differently
in
each
different
application,
and
so
cannot
be
directly
transformed.
For
example,
for
a
Country
attribute,
one
application
might
use
a
two-letter
code
(such
as
US,
FR,
or
EG)
while
another
application
uses
a
numeral
(such
as
1,
2,
or
3).
To
associate
such
attributes
between
different
applications,
you
create
a
relationship
definition
,
associating
the
data
of
the
source
and
destination
attributes.
Most
maps
use
one
or
more
relationship
definitions.
Both
map
and
relationship
definitions
reside
in
the
repository
of
InterChange
Server
Express.
Like
business
object
definitions,
relationship
definitions
function
as
specifications
or
templates
for
the
instances
that
are
created.
Unlike
instances
of
business
objects,
relationship
instances
persist,
and
are
stored
in
special
tables
for
each
relationship.
Each
time
the
system
receives
a
request
to
transform
a
given
business
object,
it
executes
the
associated
map,
and,
depending
upon
the
purpose
of
the
transformation,
creates
one
or
more
instances
of
its
associated
relationship
definitions.
Relationship
instances
created
during
map
execution
contain
the
runtime
data
from
the
attributes
they
associate,
and
this
data
is
stored
in
relationship
tables.
Communication
transport
infrastructure
Administrative
interactions
between
distributed
InterChange
Server
Express
components
are
enabled
by
the
Common
Object
Request
Broker
Architecture
(CORBA).
Content
data
transfers--that
is,
the
business
data
that
is
being
exchanged--can
utilize
either
CORBA,
or
messaging
technology
provided
by
the
Java
Messaging
Service
(JMS)
using
WebSphere
MQ
queues.
CORBA
The
Common
Object
Request
Broker
Architecture
(
CORBA
)
defines
a
set
of
standards
and
interfaces
for
distributed
objects
on
a
network.
The
Object
Request
Broker
(
ORB
)
is
a
set
of
libraries
and
other
components
that
client
applications
and
object
servers
use
to
communicate.
InterChange
Server
Express
uses
the
IBM
Java
ORB
product.
The
ORB
makes
InterChange
Server
Express
accessible
to
its
clients,
the
connector
agent,
and
System
Manager.
An
InterChange
Server
ExpressExpress
instance
registers
with
the
ORB’s
name
service,
from
which
a
client
obtains
the
information
it
needs
to
find
and
start
interacting
with
the
server.
The
client
and
server
perform
object-to-object
interactions
by
means
of
the
ORB’s
Interface
Definition
Language
(IDL).
At
a
transport
level,
they
communicate
by
means
of
the
Internet
Inter-ORB
Protocol
(IIOP).
ORB-based
communication
is
typically
used
for
the
following
purposes:
v
The
Server
Access
Interface
uses
ORB-based
communication
to
handle
calls.
v
Optionally,
in
request/response
interactions,
collaborations
and
connectors
use
ORB-based
communication
to
exchange
business
objects.
v
A
connector
agent
uses
ORB-based
communication:
16
IBM
WebSphere
Business
Integration
Server
Express
and
Express
Plus:
System
Implementation
Guide