What is T3, soadirect, sb? When to use them?

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!!

Oracle OSB Sample Examples (Getting Started with Oracle OSB)

http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/examples/samples.html
http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/tutorial/tutGettingStarted.html
http://www.oracle.com/technology/sample_code/products/osb/samples/osb_examples_tutorials_0.pdf
http://www.oracle.com/technology/products/soa/service-bus/collateral/osbsamples.html
http://www.oracle.com/technetwork/articles/jumpstart-for-osb-development-page--084104.html

Guide to install Eclipse for Oracle OSB

http://blogs.oracle.com/middleware/entry/installing_eclipse_for_osb_development

OSB Cluster- WSDL Endpoint changes to Managed Server Host/Port on fetch

On fetching a WSDL from a OSB Cluster (ManagedServer1 ... ManagedServerN) with a load balancer sitting in front and if the endpoint URL gets set to a particular ManagedServer (Host/Port), then you cluster is not load balanced. If the client application caches the WSDL then you are in deep trouble and is not the right behaviour. In order to make it correct, do the following:

Put the LoadBalance (IP/Port) in Weblogic Admin Console at the following location:

Home -> osb_cluster ->Summary of Environment ->Summary of Clusters -> osb_cluster -> configuration -> HTTP sub-tab

Restart the managed servers and try fetching the WSDL and the endpoint service URL should be set to LoadBalancer (IP/Port) and not any of Managed Server (IP/Port). This should be done for every OSB Cluster with a load-balancer in front

OSB vs BPEL

One of the fundamental concepts of SOA is service reuse. There are significant cost benefits to reuse. This involves discipline and governance in defining the interfaces of the services to be reused. However it is not reasonable to re engineer all your existing applications to be reusable. What is required is service virtualization by a layer in front, which has the architected controlled reusable interfaces. This interface needs to be governed through an enterprise repository and discovered for reuse through a service registry.

Another problem is that application interfaces change over time as business requirements change and evolve. However in a successful SOA practice, these applications are heavily reused with lots of clients. The change to the interface has a ripple effect across all the clients who need to absorb the change. What is required is agility in the IT systems to minimize the impact of such changes so such changes can be done quickly and easily. This not only has cost benefits but also business benefits due to agility to meet new business requirements. To achieve this, we need a virtualization layer in front that the many clients talk to, which can be the point of absorption of most such changes.

Oracle Service Bus (OSB) is a high performance stateless enterprise service bus that provides this virtualization layer that facilitates reuse. OSB deals not only with XML interfaces but also binary, text, java(future) and structured binary (example SWIFT) interfaces. All these data types can be natively stored in OSB variables.

What are the types of changes OSB can absorb? OSB can largely absorb all of the following changes. As one of many examples, you do not want to constantly modify a BPEL process for all these changes but rather abstract out these changes to OSB in front of or behind the bpel process.

- Changes to the document format, say due to xml schema changes or even changes to the version of structured binary data. Transformation can be done by java code, XSLT, Xquery, or MFL to convert between structured binary and XML. OSB supports any to any bridging between formats.
- Changes to packaging say from soap 1.1 to soap 1.2 or even from REST to soap.
- Changes to where the messages need to be routed or load balanced.
- Changes to the location of a service (change in address).
- Changes to the security scheme, say from HTTP basic auth to web services security username token.
- Changes to the transport, say from HTTP to JMS. OSB supports a large number of transports and you can also seamlessly plug in new transports. OSB supports any to any bridging between transports.
- Changes to the invocation style say from one-way to request/response. OSB supports any to any bridging between supported invocation styles.
- Changes to what data the message is enriched with. OSB has a variety of ways to lookup data. You can lookup data in a databases or invoke web services or java code to do lookups.
- Split of a service or operation into multiple services or operations that need to be invoked in sequence or in parallel or a mix of the two. Alternatively merge of a set of services or operations into a single service or operation.
- Changes to the routing rules.
- As service reuse increases, the service gets overloaded and needs to be throttled.

Even if there are no difference initially between the OSB interface and the enterprise services it virtualize it is good to architect in OSB as an intermediary for more easily handle future changes.

BPEL on the other hand is focused on orchestration of long running or short running processes. The core of a process logic is implemented as a BPEL process.
The focus is very different. You would NOT put process logic in OSB.