Weblogic installation provides a range of standalone client that access WebLogic Server applications range from simple command-line utilities that use standard I/O to highly interactive GUI applications built using the Java Swing/AWT classes.
T3: RMI communications in WebLogic Server use the T3 protocol to transport data between WebLogic Server and other Java programs, including clients and other WebLogic Server instances. A server instance keeps track of each Java Virtual Machine (JVM) with which it connects, and creates a single T3 connection to carry all traffic for a JVM.
SOADIRECT: The SOADIRECT transport provides native connectivity between Oracle Service Bus and Oracle SOA Suite service components. Oracle SOA Suite provides a "direct binding" framework that lets you expose Oracle SOA Suite service components in a composite application, and the Oracle Service Bus SOA-DIRECT transport interacts with those exposed services through the SOA direct binding framework, letting those service components interact in the service bus layer and leverage the capabilities and features of Oracle Service Bus.
SB Transport: SOA Suite can invoke Oracle Service Bus proxy services with an SB transport binding, including the transaction and security context using the direct binding reference.
You can google for more details on each of them. Now, all of the above internally uses RMI/t3 for protocol for communication But, I could not find any specific internals about how t3 works and most importantly how to load balance these using software/hardware load balancer. In this blog, I will reveal the details that I got from the experts:
1. Can you loadbalance t3 connections?
You cannot explicitly load balance t3 connections. So, even if you put a hardware/software loadbalancer in front of SOA/OSB/Weblogic cluster it would not help. Yes, the initial connection request will go through the load balancer (only as part of connection establishment i.e. as an alternative to DNS round-robin) but after the intial connection is established, it will stay for the lifetime of the server or client. Once a connection(t3) is established, it consistently goes routes back to the same server directly without going through the loadbalancer. If the connection fails, the loadbalancer doesn't attempt to re-establish it. Responsibility for failover and reconnection remains with the t3 protocol itself.
2. What happens when the client/SOA/OSB requests a t3/soadirect/sb connection?
In general, t3 takes care of its own load balancing (stateless stubs will round-robin calls; stateful stubs will be sticky, with appropriate failover), but requires unfettered access to establish connections to the target servers. Further, once a client has made a connection to one node in the cluster, it learns about all cluster members (regardless of the contents of the URL used to connect); and is actively notified of the member health so it will rarely try to contact a server that is not running. T3 is a stateful protocol; once a connection has been established, the LB cannot re-route it. Responsibility for failover and reconnection must remain with the RMI stub.
3. What happens if the connection is dropped?
Once the channel (t3) is established, the two endpoints will issue regular heartbeats and keep the connection alive.
4. how can you loadbalance your t3 connections?
No, you cannot loadbalance them so it is recommended to not use it until you need to propogate transactions as t3 provides transactional capabilities. You may some link specifying that soadirect/sb/t3 is faster than regular http/ws but I would recommend don't believe it until you test it in your environment.
Bottom line: Use sb/soadirect/t3 only if you need to propogate transactions between end systems else don't use it!!
