2010-05-14

Installing SOA Suite 11gR1 PS2 on Windows Se7en (64 bits)

 

image image

 

When I first started to configure the SOA Suite, it was a bit … messy (I tried to manually migrate 10g on WLS).

Now the brand new 11gR1PS2  has been out for a couple of weeks, I wanted to install and test it on my W7 64 bits laptop.

But even if I found some documentation (post by Demed L’Her and the official documentation),

it wasn’t that easy to find a proper modus operandi for a 64 bits Windows platform.

On top of that, the latest patchset (PS) is not autonomous : you have to install the previous PS first.

 

1) Downloading

 

First step : get the required files !

Fortunately, you don’t need to download all the files composing the PS1 and the PS2.

  1. Download a 64 bits JDK from Sun
  2. Go to OTN and download the following products :
  3. Optional but recommended : SQL Developer.

 

2) Installing

 

2.1) JDK 64 Bits

 

First of all, we have to install the JDK 64 bits.

Wherever you want to install your JDK, it will install a part of your JDK in the directory “Program Files” (C:\Program Files\Java\jdk1.6.0_20)

Note : “Program Files (x86)” is for 32 bits software and “Program Files” is for 64 bits software.

 

2.2) JDeveloper & embedded WebLogic Server (64 bits)

 

To execute the installer in 64 bits, you have to specify the option “-D64”, such as : java –D64 –jar jdevstudio11113install.jar

 

image

 

Choose a proper middleware home. I advise you to chose a directory structure like this one :

 

image

 

As JDeveloper comes with its own version, it is important to prevent any conflict between both WLS versions (according to Demed L’Her).

 

As we downloaded the generic version of JDeveloper, there is no bundled JDK (which is pretty much what we wanted since we already installed one)

Therefore, the installer will ask you for a JDK location : chose the freshly installed one (normally located in C:\Program Files\Java) :

 

image

 

At the last screen, uncheck “Quickstart” and click “Done”.

EDIT Important note : I was a bit too optimistic to think it would allow JDev to run in a 64 bits mode. When I tried to start, it simply refuses to launch.

Then, I’m really sorry, but you will still have to install a 32 bits JDK to be able to run it. WebLogic Server will run in a 64 bits mode though.

To update the JVM location, edit the file JDEV_HOME\jdeveloper\jdev\bin\jdev.conf and update the field SetJavaHome

Then update it to get the SOA module.

image

 

Leave only “Oracle Fusion Middleware Products” checked.

 

image

 

Type “soa” in the search field, and check the “Oracle SOA Composite Editor

 

image

 

Then the download starts.

 

image

 

Once the download is over, you are done with JDev.

 

2.3) WebLogic Server 64 bits

 

At that point, you may wonder why we are installing once again WebLogic Server, because as we saw it, it is bundled & normally installed with JDeveloper.

This question is legitimate. The WLS shipped with JDev is not “strong” enough : I mean, it is only a light version, designed to work mainly with ADF.

You will then not be able to use the SOA Suite on that version, that is why we must install the “real” one.

 

Using the generic installer, just type : java –D64 –jar wls1033_generic.jar

 

image

 

As detailed in the JDev installation step, it is better if you do not mix up the WLS versions, so create another middleware home, such as :

 

image

 

Then, just like for JDev, chose a proper JDK location.

 

image

 

At the last screen, uncheck “Quickstart” and click “Done”.

 

2.4) Database : Oracle XE

 

Just install the product. Nothing hard here.

Note that the principle of XE is to have only one instance (XE) but as many users (schemas) as you want.

Chose a password for sys & system (it’s the same for both) and be sure to remember it.

“manager” is a good development value as it is commonly used almost everywhere (even in production sometimes :p) : easy to remember.

Once you’ve installed the database, you’ll have two services installed (OracleXE & Oracle TNS Listener),

and an administration interface will be available on port 8080, at the address : http://localhost:8080/apex

 

image

 

You can use it to administer some parts of your database (user creation and so on, but unfortunately, no tablespace management …)

 

Update the numbers of processes

 

If you run the RCU (described in next section), you will see that the test for user SOAINFRA fails.

The reason comes from the number of processes which is, by default, not high enough.

We then need to execute this SQL instruction to fix that :

alter system set processes=200 scope=spfile

(SCOPE = SPFILE / MEMORY / BOTH) (SPFile has to be binary)

Oracle XE will not let you change the value of the parameter in memory, so you have to chose SPFILE and then restart your database.

After the restart, to confirm that your change has been taken into account, execute this instruction :

select value from v$parameter where name = 'processes'

It should return the value you defined, that is to say, 200.

Okay, now let’s create the schemas !

 

2.5) RCU (Repository Creation Utility)

 

There’s nothing to install from a software point of view : a wizard will just configure your database by creating the required users.

Unzip the file “ofm_rcu_win_11.1.1.3.0_disk1_1of1.zip” in a folder I will now refer to as “UNZIP_FOLDER”.

Note : For the SOA Suite to work, you are not forced to keep the RCU after the job is done : it is a one-shot configuration

Launch the file UNZIP_FOLDER\rcuHome\BIN\rcu.bat

 

Configure the access to your XE database :

 

image

 

You may have some warning about the encoding : no big deal, click ok (maybe twice) and then you will have this screen

 

image

 

Click “OK”. The RCU will now ask for a prefix. Usually, for a development environment, “DEV” fits :)

So that is the prefix we are going to define here.

Just select SOA & BPM Infrastructure and will check its dependency (MDS).

 

image

 

Then go forward : the RCU will handle the tablespaces & users for you

 

image

 

Note : If you were ever forced to drop some schema, know that you may have to execute this procedure to be able to get rid of the SOAINFRA schema.

BEGIN
  DBMS_AQADM.DROP_QUEUE_TABLE('EDN_OAOO_DELIVERY_TABLE', FORCE => TRUE);
  DBMS_AQADM.DROP_QUEUE_TABLE('EDN_EVENT_QUEUE_TABLE', FORCE => TRUE);
  DBMS_AQADM.DROP_QUEUE_TABLE('IP_QTAB', FORCE => TRUE);
END;

A summary screen will show you the information you entered :

 

image

 

Click “Create”.

Normally, everything should go painlessly and at the end, another summary screen will show up :

 

image

 

Close the window and you’re done with the RCU.

 

2.6) SOA Suite PS1 (11.1.1.2)

 

So as I wrote it in the introduction, you’ll have to install the first patchset, then then second one.

  1. Unzip the file ofm_soa_generic_11.1.1.2.0_disk1_1of1
  2. Go in UNZIP_FOLDER\Disk1 and run setup.exe
  3. A DOS window will ask you to enter a JAVA_HOME

 

Enter the path to the JDK in “Program Files”

 

image

 

The DOS window will then vanish, and the Oracle Universal Installer will pop up :

 

image

 

Chose the WebLogic Home in which you installed WebLogic Server 64 bits ([…]\SOASuite11gR1PS2\OFM)

Make sure that the “Oracle Home” has the proper value.

 

image

 

Then click install on the next screen.

 

image

 

You should normally have in your MIDDLEWARE_HOME the following directory structure :

 

image

 

2.7) SOA Suite PS1 (11.1.1.3)

 

Now it’s done, we will upgrade our SOA Suite with the latest patchset.

In a word, it’s just like the PS1 : you first have to unzip the file “ofm_soa_generic_11.1.1.3.0_disk1_1of1.zip” and then execute the setup.exe in the directory “Disk1”.

You will be asked to enter the original directory in which you installed :

  • your Oracle Middleware home (SOASuite11gR1PS2\OFM)
  • your Oracle SOA Suite directory (Oracle_SOA)

 

image

 

And here you go again :)

 

image

 

But this time note the versions that are displayed : they’re all in 11.1.1.3.0.

 

Okay now’s everything is configured.

 

3) Checking

 

3.1) 64 bits installation

 

This part is optional : just to check that WLS was correctly installed in 64 bits, you can create a sample domain, start your server and check the following :

starting weblogic with Java version:
java version "1.6.0_20-ea"
Java(TM) SE Runtime Environment (build 1.6.0_20-ea-b02)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b12, mixed mode)

And :

<14 mai 2010 01 h 20 CEST> <Info> <WebLogicServer> <BEA-000377> <Starting WebLogic Server with Java HotSpot(TM) 64-Bit Server VM Version 17.0-b12 from Sun Microsystems Inc.>

You should also see some references to the native 64 libraries in the PATH :

[…] \server\native\win\x64 […]

 

3.2) SOA Suite PS2

 

Check that all the templates are available.

 

image

 

 

4) Conclusion

 

It is an official recommendation to install JDev in a directory and the SOA Suite in another, but I made a test in which I did override the WLS installed by JDev and it seemed to work.

Some stuff I found weird : in the “SOASuite11gR1PS2\OFM\wlserver_10.3\common\bin” directory when I run config.exe, I don’t have the same result as if I had run config.cmd

 

config.exe gives me :

 

image

 

Whereas config.cmd gives me :

 

image

 

Got to check whether this a common behavior or not ! :)

 

2010-05-09

Shared Libraries versus Optional Packages

Starting with WebLogic Server 9, BEA introduced an interesting concept aiming at sharing more easily libraries between EARs.
From a performance point of view and memory imprint, there’s absolutely no change : the library will still be loaded in each and every EAR classloader.
But from a packaging point of view, it allows you to reduce significantly the size of your archives, by externalizing the common libraries.
Moreover, when you have to upgrade one of your lib, it’s easier to do, thanks to centralization.

In my case, I’m currently working on a key SOA project on which a huge work had been done on isolating services from a business point of view.
But technically, all the services were packaged in the same EAR, which is a serious problem for the high availability we are supposed to provide.
(in case of a new version, it would lead to an undeployment of the whole archive : production redeployment is not an option since the archive is pretty bulky)
So I had to explode the EAR in several WARs and adopt a strategy for the library sharing.

Deploying libraries


First of all, whether you'll use the “shared library” or the “optional package” mechanism, your libraries (JARs in our case but can be WAR, RAR …)
must respect a certain definition in their manifests, such as :
Extension-Name: fr.mbutton.blog
Specification-Vendor: Tengah Consulting 
Specification-Version: 1.0 
Implementation-Vendor-Id: fr.tengah-consulting 
Implementation-Vendor: Tengah Consulting 
Implementation-Version: 1.1
This example has been inspired by the example found on sun.com.
Based on my experience, the only lines that really matter are the following :
Extension-Name: fr.mbutton.blog
Specification-Version: 1.0
Implementation-Version: 1.1
WebLogic Server will use the extension name to determine the name it will use for the library you’re deploying.
If none, then the name of the file itself will be used to qualify deployed archive name, as explained on Oracle documentation.

In my case, I had to list all the libraries used in our application and see whether they were eligible for being deployed as a shared library.
And I realized that lots of libraries you can find on the market are / were not thought to be deployed as optional package / shared libraries.

So far, the only libraries that were clearly designed following this standard are the libs from Apache.
Regarding the specification & implementation versions, you may specify those pieces of information while deploying,
but it is a good practice to have them described in the library manifest.

Moreover as described in the official Oracle documentation, you should be careful while using this modus operandi :
“If both the manifest file and the weblogic.Deployer command line specify version information, and the values do not match, the deployment fails.
If you initially registered a library without providing a specification or implementation version,
you must undeploy the library before registering a newer version and specifying version string information.

You can register multiple versions of a library or package, but each version must use the same version strings.
For example, you cannot register a library having only a specification version,
and then register a new version of the library having both a specification and an implementation version.”
Referencing Shared Libraries

Now our libraries are correctly defined and deployed the use as shared libraries is really simple.
According to the documentation about the weblogic deployment descriptors (weblogic.xml & weblogic-application.xml), the way to reference a library is the following :
<library-ref>
    <library-name>fr.mbutton.blog</library-name>
    <specification-version>1.0</specification-version>
    <implementation-version>1.1</implementation-version>
    <exact-match>false</exact-match>
</library-ref>
But one major problem is that you cannot reference all the types, just as it is clearly said in the official documentation :
“You cannot reference any other type of shared Java EE library (EJB, Enterprise application, or plain JAR file)
from the weblogic.xml deployment descriptor file of a Web Application.”
In other words, it is impossible to reference JAR files in a web application (WAR).
Hummmm … annoying since it’s exactly what I’m trying to do …
Then my friend & colleague Romain told me about the optional packages.


Referencing Optional Packages

With optional packages, that annoying limitation is no more.
If you followed the pieces of advice regarding the correct deployment of libraries for a use as shared libraries,
that’s perfect because you won’t have anything to change to switch to optional packages.

The only thing that changes is the way you will refer to them.
Using optional packages, you simply have to update the manifest for your WAR such as :
Extension-List: blog
blog-Extension-Name: fr.mbutton.blog
blog-Specification-Version: 1.0
blog-Implementation-Version: 1.1
And suppose we have another library :
<library-ref>
    <library-name>org.springframework</library-name> 
    <specification-version>3.0</specification-version> 
    <implementation-version>3.9beta</implementation-version> 
    <exact-match>false</exact-match> 
</library-ref>
This time, the definition in the manifest would be :
Extension-List: blog spring
blog-Extension-Name: fr.mbutton.blog
spring-Extension-Name: org.springframework
blog-Specification-Version: 1.0
spring-Implementation-Version: 3.9beta
Once again, I’m not inventing this : you can read it here.

Finally …

Okay here we are, time for a conclusion !

Shared libraries :
  • are cool but do not allow all type of referencing (-)
  • are WebLogic Server specific (-)
  • are XML based (+?)
Whereas optional packages :
  • are standard … (+)
  • … but completely based on manifests : almost worst than Cobol ! (-)
  • allow a lot more possibilities (+)
Hope this post helped to enlighten a bit your path.

Resources :

Mots clés Technorati : ,,,,

2010-05-06

About some of the tools I am using in my everyday life

As a consultant, I'm always on the run, switching from clients to others, resolving (or at least, trying to) problems.

(even if it's not been the case lately, since I'm working for a very large client who needs a lot of attention :p)

Anyway, I could not do my job without my tools. And as they are very very useful to me, I wanted to share them with you !

Sorry Aurélien for taking your blogpost idea, but I’ve been waiting about a year for your blog to be created, and I’m still waiting ;)

 

Network (tools to grab some remote files, setup a FTP server ...)

 

First of all, Putty. Very famous SSH client I find very useful BUT even more when used within Putty Connection Manager.

The latter is a layer above putty that allows you to centralize all your putty windows, enter some extra-commands, such as auto-login etc.

I'm using it everyday !

 

Then, when you want to browse a remote server windows-style, you may use a FTP client (of course,

only if the server you want to reach is running a FTP server).

In that case, the most famous FTP client is probably FileZilla. If you want to serve your files through FTP,

you may use FileZilla Server or Serv-U FTP, which is pretty good too (but not free).

Else, I use WinSCP, SFTP / FTP but also SCP client.

 

When you really want to know what’s going on& what’s exchanged between two servers, you may use Fiddler to watch HTTP traffic.

And if you want to “go deep”, use WireShark.

 

If you’re looking for a cool & free LDAP client, then forget about Softerra & JXplorer !

Try Apache Directory Studio and you’ll see what I mean …

 

Database

 

Well, all depends on the database manufacturer you're relying on. Personally, it's Oracle (no kidding).

Then as my personal database, I'm using Oracle XE, and as a client, I'm using Oracle SQL Developer, which is pretty good.

 

Java / Java EE

 

I will not start a war by saying that my IDE is the best :)

I’m using Workshop (Eclipse with a BEA flavor) but it’s more a pain in the … than everything else !

I remember enjoying IntelliJ Idea but it was a long time ago. NetBeans has a pretty good reputation !

I have been playing with JDeveloper and even if it took me a while to get used to it, I can say it’s not bad, rather good in fact.

Finally, I would go for Eclipse without the bunch of annoying plugins brought by Workshop.

 

When I’m stuck on a common error such as “NoClassDefFoundError”, my life saver is “Jar Finder”.

You may find some other ways to do so, such as websites, Eclipse plugins etc,

but I can assure you that there is nothing better than this tool !

Quick to start (no workspace to load …, can use it offline) and pretty efficient : the must-have.

 

And sometimes, when I want to take a closer to look to an implementation, I use JD-* (Java Decompiler) which is an excellent,

I would even say the best tool to assist you in decompiling Java classes.

(and the fact it’s been written by a former colleague has nothing to do with it ! :D)

 

As everyone using webservices, I’m using SOAPUi (which allows you in its latest version to do some stress test too !)

 

And when I have to perform some stress tests, I’m using JMeter (I tried once OpenSTA but was more at ease with JMeter).

 

Dealing with JMS, I’m also using HermesJMS wich is good (not always providing the best stability but cool even though).

My former colleague James blogged about it and its integration with WebLogic Server.

 

When I want to analyse some thread dumps, I’m using Samurai.


Knowledge sharing (in other words blogging !)

 

To me, online writing is not a good solution. You may lose your content, you can't write anywhere and so on.

As an offline writer, I'm using Windows Live Writer, which is pretty good. It supports a lots of blog providers :

I started with it when I first blogged on Dev2Dev on WordPress, then I switched to blogspot and WLW switched without any trouble.

 

To shoot and capture screens, I use Gadwin which can be used in a free edition and it’s excellent !

 

Other

 

Who hasn’t faced one day an annoying popup saying there was not enough space to copy a very important file ?

When such a situation happens, you can spend a lot of time looking for some files & folders to delete or you can use WinDirStat.

It’s a freeware which will allow you to find in a snap the biggest files on your harddrive.

 

I’m also currently playing with Sun’s (Oracle’s ?) VirtualBox to virtualize a whole development environment

and it’s hard not be seduced by this wonderful soft. If you try it, you will adopt it :)

 

To replace the original Windows file copying system, I’ve chosen SuperCopier. Far better !

 

And last but not least, the super text editor : Notepad++ !

If you’re working with XML : read that useful post about enabling XML indent in Notepad++.

 

Well that’s all for now and if you have an extraordinary tool you like to share, don’t hesitate to post a comment ! :)