LDAP for Authenticating Admin

This procedure explains how to enable LDAP authentication for logins to the GlassFish ESB Server Domain Administration Server (DAS). Logging in to the DAS is typically only performed by ESB Server administrators who want to use the ESB Server Administration Console or asadmin command. Environment : Glassfish ESB 2.2 LDAP Server : Apache Directory At first you need to configure LDAP authentication for admin user using following command, asadmin configure-ldap-for-admin --basedn "ou=users,ou=system" --url "ldap://localhost:10389" After this domain.xml will have following entry   <auth-realm name="admin-realm" classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm"> <property name="directory" value="ldap://localhost:10389" /> <property name="base-dn" value="ou=users,ou=system" /> <property name="jaas-context" value="ldapRealm" /> </auth-realm>   It’s not complete yet. We need to add few more optional properties. So you need to add following params   <auth-realm name="admin-realm" classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm"> <property name="directory" value="ldap://localhost:10389" /> <property name="base-dn" value="ou=users,ou=system" /> <property name="search-bind-dn" value="uid=admin,ou=system" /> <property name="search-bind-password" value="param" /> <property name="jndiCtxFactory" value="com.sun.jndi.ldap.LdapCtxFactory" /> <property name="jaas-context" value="ldapRealm" /> </auth-realm>   It’s done now (90%)… After this authentication will be successful, You can verify from command line and finest logging entries in server.log (In glassfish v3 all asadmin command requires admin password)   >asadmin set-log-level com.sun.enterprise.security.auth.realm.param=FINEST Authentication failed with password from login store: C:Userslogicoyparam.asadminpass Enter admin password for user “admin”> <type LDAP’s admin user password> Command set-log-level executed successfully.   WORK NOT COMPLETE HERE — Same thing when you try from Admin GUI, Finest logging is turned on and it says Login Successful for user admin, But after this you will not get the console, And Glassfish is not showing login screen after this. you need to restart server for login. This is the Policy issue, to resolve it open domain.xml and add...

JBI Composite Applications with JavaEE

Most of the JBI composite applications in OpenESB are written using BPEL Service Engine. This is because BPEL allows us to orchestrate various webservices. But what if one wanted to write a simple composite application without using BPEL. Let’s say someone wants to use an EJB WS as part of a larger composite application without invoking as an external webservice. By using Java EE Service Engine we will be bypassing the http layer. The JavaEE SE takes care of invoking EJB webservice from within a composite application. This blog is about creating a composite application only using Java EE SE. We will create an EJB WS and include it in a composite application. 1. Create an EJB Module 2. Name it as JavaEEEJBModule: 3. Right click on the newly created EJB Module and select “New Web Service”   4. When you click “Finish”, a new webservice with a default “hello” operation will be generated: 5. Right click on “Webservices” node and Click on “Generate and Copy WSDL”. 6. Select the conf folder under EJB. 7. Go to the newly generated WSDL, click on Design tab and add PartnerLink Type as shown below: 8. Select the Port type as JavaEEWS 9. Create a new Composite Application project:   10. Name it as JavaEEEJBCA. 11. Open the CASA editor by double clicking on “Service Assembly” under the composite application project 12. Drag the EJB Module into CASA Editor. It should look like this:   13. Right click on the composite application project and select “Clean and Build”. 14. After build succeeds, drag the soap icon from “WSDL Bindings” tab from Palette to...

Share sun-scheduler-bc jobs across instances

General Information: As we know  sun-scheduler-bc provides scheduling capabilities for initiating JBI services. The binding component is powered by http://www.opensymphony.com/quartz/, and allows you to schedule triggers to launch (consume) other JBI components. We can use this component to scheduled  “Simple“, or “Cron” or “Hybrid” trigger as we need. When you deploy any sun-scheduler based composite application into JBI container, by default its uses “Quartz RAM Store” to define its job and this is quite good if that composite application going to run in one instance. Problem with Quartz RAM Store: What happens it you going to deploy this same composite application in  multiple Cluster instances ? The answers is, trigger is going to happen in all the cluster instances at the same time and this will cause the same process runs multiple times in different instance and this is against cluster configuration. Solution: To avoid the above problem we have to perform certain configuration in sun-scheduler-bc configuration to share the quartz job details across cluster instances using “Quartz Persistent Job Store” configuration property. So that, any one of the same composite application that belongs to different cluster instances should trigger at a time. Follow the below steps to configure sun-scheduler-bc to define Quartz Persistent Job Store ( Glassfish cluster mode): Note:- In this configuration I’ve use Mysql as persistent job store to store the sun-scheduler-bc composite application job details. You can choose your own data base as per quartz api support (http://svn.terracotta.org/svn/quartz/tags/quartz-1.8.6/docs/dbTables/) Step1: To Set Up Mysql DB For Job Store 1. Create schema in Mysql db (eg: oe_sun_schedulder_bc_job_store) 2.Download the Mysql based job store sql from below link http://svn.terracotta.org/svn/quartz/tags/quartz-1.8.6/docs/dbTables/tables_mysql.sql or check this attachment for same sql scripts Quartz_Mysql_Job_store 3. Run...

Working with XSLT Service Engine: Part 2

Project summary: In This project, I am going to do xml to xml transformation using Service Bridge. Please Check working with XSLT Service Engine Part 1 for more details about XSLT Service engine and sample project for Request-Reply service of XSLT service Engine. In this sample project I am going to take customer information like Name , Address , Personal Data in separate node and then merge all above info in single node. Creating Sample Project Using   Service Bridge (xml to xml transformation) In Service Bridge we can apply multiple xml transformation on request xml and then send output back to source. We need to have same number of wsdl operation as number of transformation we want to do. In this project I am going to apply two xml transformations. So I need to create two wsdl as webservice operation to perform transformation. Let’s  say Request1 and response 1 – first operation Request2 and response 2 – second operation Client will send request via request 1 and response 1 will get back to client but over all process will something like this . (Client input xml)Request1–>apply xsl on input to generate request2–>  request 2àappy xsl on request 2 generate response 2–>  response 2 –> apply xsl on response2 to generate response1 –> response 1(client output xml). Create XSLT Module: Please refer to part 1 for details to create XSLT module. Create XSD for request and reply operation <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xml.netbeans.org/schema/CustomerDetails" xmlns:tns="http://xml.netbeans.org/schema/CustomerDetails" elementFormDefault="qualified"> <xsd:complexType name="CustomerName"> <xsd:sequence> <xsd:element name="firstName" type="xsd:string"/> <xsd:element name="lastName" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="CustomerAddress"> <xsd:sequence> <xsd:element name="HomeAddress"/> <xsd:element name="OfficeAddress"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="PersonalData"> <xsd:sequence> <xsd:element name="gender" type="xsd:string"/> <xsd:element...

Working With XSLT Service Engine: Part 1

About the XSLT Service Engine The XSLT Service Engine is a Java-based transformation engine that is used to convert XML documents from one data format to another. The XSLT Service Engine makes it easier for users to configure and expose XSL style sheets as web services. Using the XSLT Service Engine requires no special knowledge of XSL, but rather allows any XSL style sheet to be deployed as a JBI service unit. The XSLT Service Engine is not solely responsible for performing transformations. XSL style sheets implement a web service operation (as normally defined in a WSDL). When deployed as JBI service units, these service units correspond to a service endpoint. Each endpoint is activated when the XSLT service unit is deployed. In a sense, the XSLT Service Engine is a container of XSL style sheets, each of which represents a service endpoint in the JBI environment. The following steps highlight the life cycle of a typical message using the XSLT Service Engine: The XSLT service unit is configured with service endpoint information. The service unit is deplopyed, along with the XSL style sheet, to the JBI environment. The XSLT Service Engine compiles the style sheet. A message arrives and the XSLT Service Engine searches for the service endpoint responsible for handling the message. The message is transformed using the service endpoint’s XSL style sheet. A response is sent back via the Normalized Message Router (NMR). XSLT Service Engine Features The XSLT Service Engine supports the following use cases: Request-Reply Service Request-Reply is a standard request-reply scenario. An XML message request is transformed and the result is sent back...