SSAJAROFF
Reputable Poster
Hi there!
Interoperability works very well and it's a very flexible tool to
integrate OneWorld with third party products.
On B733x, Interop helps you to to invoke OneWorld functionality
from third party applications using tools far more adequate than Z1 files.
Interop may be divided into "easy" and "difficult".
"Difficult" permits you to invoke BSFN and UBEs from geeky C code, and
you get full control of threads and execution there. It's absolutely
powerful (and complex).
In the other hand, "easy" allows you to invoke BSFN from a component
point of view. You create scripts that compile a set of user-defined
BSFNs (the ones you need) and you invoke that executables from your
third party applications.
You don't bother on what's there into those boxes, just know what they
need, what they do and what they return.
Components may be DCOM compliant (that's useful to be invoked from
Microsoft products such as Visual Basic, C++, J++, Office, etc.),
CORBA compliant (more typical to Unix and AS/400 environments) and
JRIM (for Java applications, applets and servlets).
The easiest way to start is DCOM, it's free and easy to setup and use.
From my third party Visual Basic application I invoke my DCOM components
that provide BSFN functionality. Every Server BSFN can be part of
a component (Client Only BSFN don't run).
Interop solutions may be developed on a standard PC (with Windows NT),
but it's recommended that production environments dedicate a separate
server to run these Interop components.
Finally, Xe provides much more Interop tools and collaborative tools
with its XPI framework.
I recommend to read the Interoperability folder on the Deployment.
Sebastian Sajaroff
Interoperability works very well and it's a very flexible tool to
integrate OneWorld with third party products.
On B733x, Interop helps you to to invoke OneWorld functionality
from third party applications using tools far more adequate than Z1 files.
Interop may be divided into "easy" and "difficult".
"Difficult" permits you to invoke BSFN and UBEs from geeky C code, and
you get full control of threads and execution there. It's absolutely
powerful (and complex).
In the other hand, "easy" allows you to invoke BSFN from a component
point of view. You create scripts that compile a set of user-defined
BSFNs (the ones you need) and you invoke that executables from your
third party applications.
You don't bother on what's there into those boxes, just know what they
need, what they do and what they return.
Components may be DCOM compliant (that's useful to be invoked from
Microsoft products such as Visual Basic, C++, J++, Office, etc.),
CORBA compliant (more typical to Unix and AS/400 environments) and
JRIM (for Java applications, applets and servlets).
The easiest way to start is DCOM, it's free and easy to setup and use.
From my third party Visual Basic application I invoke my DCOM components
that provide BSFN functionality. Every Server BSFN can be part of
a component (Client Only BSFN don't run).
Interop solutions may be developed on a standard PC (with Windows NT),
but it's recommended that production environments dedicate a separate
server to run these Interop components.
Finally, Xe provides much more Interop tools and collaborative tools
with its XPI framework.
I recommend to read the Interoperability folder on the Deployment.
Sebastian Sajaroff
