This content has been marked as final. Show 3 replies
I'm no expert on protocols, but I think it all depends on your architecture - especially where you choose to install the adapters.
There are different OAI topologies, but typically most clients have all the interconnect products installed on one server. The reason for this is that communication between the adapters and the
-- Oracle AQ (to enqueue / dequeue messages) is done via JMS,
-- Repository Java Service (to get the metadata, CBR rules) is done via CORBA over IIOP and
-- Repository Database (used to insert/update runtime data like tracking fields, error messages ) is done via JDBC thick client using SQLNET
-- third-party uses "native" protocols like FTP or SQLNET over TCP/IP. This means that most firewalls can more easily be configured for these protocols and port numbers.
The Adapter process loads all the metadata (ie the transformation rules, CBR etc) during the startup provided, it is mentioned in the adaper.ini and applies the rules at the runtime. I
Normally, the adapter process doesn't lookup the repository for every message. However, it does a lookup at the repository tables only if there is a DVM or an XREF involved in the tranformation.
My understanding is that the adapter spawns two threads a Reader (for Publishing messages) and a writer (for subscriibing messages). There is no Java middleman it is all controlled within the same java process.
Ian is right about the various protocols but you have various options in the adapter.ini files that will vary the behaviour of repository calls for CBR rules, DVM look ups etc... You can cache these locally if you know they are going to be heavily used.
The adapters all run as independant processes (although the corba addresses are stored in the Hub), when an adapter picks up a message to send to the Hub, the adapter determines what adapters want it and the adapter (agent) will write to the AQ with the relevant number of subscribers. So if App1 and App2 both want the same message then a single message is written to the Q, with consumers for App1 and App2. The App1 and App2 adapters are polling the Q to see if there are any messages for them. If there are then they will dequeue them.