Using HTTP instead of T3 for WebLogic Scripting Tool (WLST)

A friend of mine asked why the WLST connection from the Jython based scripting tool is only working with t3. IMHO using t3 for WLST is not a big deal since it is a WebLogic tool talking to WebLogic itself, and t3 was built and optimised for that.

You might want to replace t3 with HTTP anyway, e.g. for one the following reasons:

– for the sake of standards, you want to use as many standard protocols as possible. t3 is WebLogic vendor specific.

– you might have problems with t3 when connecting through firewalls.

 

Easy Solution

Here is the good news. Unknown to many, WLST does work with HTTP if you enable tunneling for the Admin server ( Admin Server / Protocols / General ).

Screen Shot 2015-03-02 at 10.24.50

then it’ possible to use HTTP for WLST:

wls:/offline> connect('weblogic','welcome1','http://localhost:7001')
Connecting to http://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server "AdminServer" that belongs to domain "simon".
Warning: An insecure protocol was used to connect to the 
server. To ensure on-the-wire security, the SSL port or 
Admin port should be used instead.

Using a Network Channel

Alternatively if you want to separate the admin traffic but not use SSL (which would be enforced e.g. by using the administration port feature of WebLogic), you could create a network channel under Admin Server / Protocols / Channels for the t3 protocol, e.g. on port 8888 and enable “Tunneling” for that channel. Note that http is already enabled for the channel but this is not enough, you must enable tunneling.

Screen Shot 2015-03-02 at 10.15.29

 

Administration Port

The third and most secure possibility of course is using tunneling in combination with the administration port.

 

Comments:

– You do not need the administration port for using WLST with HTTP.

– It’s not required to change WLST from t3 to HTTP. This posting only shows how it can be done if one of the reasons above apply to you.

– Changing other clients from t3 to IIOP or so, e.g. JMS clients or standalone Java clients using RMI typically has more implications which are not discussed here.

 

More?

If you want to learn more about the basics WebLogic scripting tool I recommend to start with the following web cast.

WebLogic 12.1.3 New Unicast Group Implementation

As of WebLogic 12.1.3 the implementation of unicast groups used for WebLogic clusters has changed.

What is new?

  1. There is a fixed maximum number of groups which is 10.
  2. Groups can be asymmetric.
  3. Servers are put into groups based on the hash value of their name (which obviously explains 2).

The group leader in a particular group might change if new servers are added but with dynamic clusters and generated cluster names this is rather unlikely.

Why?

The implementation has changed to make it more robust. The official Oracle documentation was initially wrong, but has been updated now.

Example

When creating a classic cluster with servers surf1, surf2, surf3 or servers abc, jkl, xyz, every server ends up in its own unicast group, the total number of groups is the same as the number of servers.

When creating a dynamic cluster with let’s say 15 servers, server server-1 and server-11, server-2 and server-12, etc. are grouped together into one group.

unicast groups dyn cluster

More?

It is not yet officially documented. Currently the official Oracle documentation still describes the old implementation. I described the new implementation in my Oracle Open World presentation together with Dave Cabelus.

Also there is a short web cast available here:

12 Things about WebLlogic 12.1.3

While you’re at it, make sure to download my Oracle Open World 2014 presentation slides for more ideas of what is new and newsworthy in WebLogic 12.1.3.

New RESTful Management API in WebLogic 12.1.3

What you should know:

WebLogic 12.1.3 comes with a new implementation of the RESTful management interface.

Why RESTful?

RESTful interfaces are interesting because they …
– can be used from any language (UNIX curl, Python, Java, you name it …)
– are leight-weight. All you send is an URL using http (and possibly some JSON data)
– are leight-weight on the client side. No JVM is required, unlike let’s say JMX.
– can easily be used across firewalls because the underlying protocol is http.

What is new?

Unlike previous versions of the management interface, WebLogic 12.1.3 provides a technically better implementation for RESTful management, since the interface…
– incorperates versioning
– uses canonical URLs
– uses the well-known http verbs GET (to retrieve information. e.g about a configured data sources), POST (to create e.g. a new data source), OPTIONS (to create a JSON data structure used as a template for create a new datasource), DEL (to delete a datasource).
– returns RESTful URLs in the response.

What is missing?

Currently there is no support for JMS, Workmangers, etc. Since there is no generic way of accessing MBean attributes in WebLogic’s implementation of the RESTful management interface you have to wait for Oracle to implement support for those ressources.

Gossip is spreading that the missing ressources will be included in WebLogic 12.2.1.

More?

more information can be found in the Oracle documentation. There are also some web casts available on the WebLogic Book Youtube channel.

Even More?

I recorded a 2 minute tech-tip for OTN. Previously I explained how the open source Jolokia alternative can be used together with WebLogic.