Weblog for the AMIS Technology corner
Posts tagged soa suite
Publish SOA Composite application as EJB to be invoked from Java applications using EJB Binding
Jun 14th
With the recent (April 2010) SOA Suite 11g R1 Patch Set 2 (11.1.1.3.0), several new capabilities have been added to the SOA Suite. One these is the EJB Binding. Or rather, an enhanced version of this binding. In previous releases, this binding was available to provide interaction with SDO enabled EJBs – based on a WSDL interface and XML messages. The PS2 release added full Java support to the EJB binding. This means that we do not have to concern ourselves with WSDL and XSD that maps to the Java interface we want to invoke or expose, nor with sending a XML based payload when we invoke the composite service. All we need is the Java interface that describes either the EJB that we want to invoke (for an EJB Binding Reference) or that we want to expose (for an EJB Binding Service).
Steps:
1. Create Composite like always
2. Create a Java Interface (and possibly Java domain classes or bean types describing the structure of the input and ouput of the methods on the EJB (that should correspond with the operations available in the Composite application)
package nl.amis.utilities;
public interface FilterAndTranslate {
public String translate(String input);
}
Note: steps 1 and 2 can be reversed; especially when you want to work according to the contract (or design) driven approach, that would probably be best.
Note: thusfar I have only been successful with a Java interface that only uses simple types (my own domain objects and beans prevented deployment of the EJB for some reason)
3. Create an EJB Binding in the Services lane, based on this Java interface. Specify the JNDI Name for this EJB. For example: FilterAndTranslateEJB
Starting WebLogic managed servers without providing username and password manually – SOA Suite 11g tip
Sep 24th
After installing the Oracle SOA suite 11g, you will notice that you have to enter username and password for each managed server during startup and shutdown. This in contrary to the administration server where you don't need to enter username and password at startup. I was wondering if there was an easy way of skipping this manual step for the managed servers as well.
And yes, there is an easy and elegant way to prevent entering credentials every startup and shutdown. Just follow these steps:
1 Create a boot.properties file.
Create a plain text file called boot.properties with the following content:
username=scott
password=tiger
2 Place the boot.properties file in the security directory.
Save or copy this file in the security directory under the managed server root directory. This directory was not created at installation time, so I had to create it myself. The server root directory is located at <middleware_home>\user_projects\<domain>\<managed_server> i.e. D:\Middleware\user_projects\domains\base_domain\servers\bam_server1.
3 Start the managed server.
The server will read the credentials from the boot.properties file and in case of plain text username and password the server encrypt the username and password. Notice the following lines in the output:
<Sep 23, 2009 10:51:25 PM CEST> <Notice> <Security> <BEA-090082> <Security initializing using security realm myrealm.>
<Sep 23, 2009 10:51:25 PM CEST> <Notice> <Security> <BEA-090083> <Storing boot identity in the file: D:\Middleware\user_projects\domains\base_domain\servers\bam_server1\security\boot.properties>
The boot.properties file is still plain text with the username and password values encrypted. Do no copy the encrypted version between managed servers. Even when the credentials are the same, the resulting file is different.
For more information and alternatieve solutions see Creating Boot Identity Files for Managed Servers.
