Thursday Oct 01, 2009

Fuji simple service API and springDM

 What is Fuji simple service api?



The simple service provides the capability to invoke/interact with JAVA code outside of  JBI, Simple Service API provides a bridge between code that is hosted outside of a JBI component and service endpoints available on the NMR. The interface below shows what a user need to do in-order to use simple service api while provisioning an osgi service. for details see Fuji Simple Service API




/\*\*
 \* This interface represents a simple service provisioning contract with the
 \* JBI runtime environment.  The invoke method is called when a message
 \* exchange is addressed to this service instance.  Classes implementing this
 \* interface must be registered in the OSGi service registry in order to be
 \* available to consumers in the JBI runtime environment.  Further, the
 \* service registration must contain a property called "org.glassfish.openesb.serviceName" which
 \* contains the name of the service being offered.  Optionally, a property
 \* called "org.glassfish.openesb.endpointName" can also be specified.
 \* 
 \*/
public interface ServiceProvider { 
    ServiceMessage invoke(ServiceMessage message) throws Exception;
}


This blog shows how to integrate Fuji simple service api with spring/springDM  application, We will create a springDM application which instantiates the above provider Implementation , based on spring-config and spring-osgi-config files . In the diagram below the service provider is part of the spring application and the application context is created by the springDM module




Create a new springDM module, The Spring-OSGi project supplies a maven archetype that will create a SpringDM bundle project , example




 mvn archetype:create   -DarchetypeGroupId=org.springframework.osgi  
-DarchetypeArtifactId=spring-osgi-bundle-archetype 
-DarchetypeVersion=1.1.0  
-DgroupId=org.foo 
-DartifactId=org.foo.springdm.fuji
-Dversion=1.0

The structure of the project will look as below


 spring DM project



Change the pom , add dependency of the Fuji api



 go the src root of the application and add the following dependency to the springDM module pom




<dependency>
   <groupId>open-esb.fuji</groupId>
   <artifactId>api</artifactId>
   <version>1.0-M9-SNAPSHOT</version>
</dependency>



Write the POJO which implements ServiceProvider , note this POJO is part of the spring application, and can access any bean or the spring applicationContext, In the above diagram  org.foo.MyProvider.java , represents the POJO which implements the ServiceProvider Interface. here is a sample code




package org.foo;


import org.glassfish.openesb.api.service.ServiceMessage;
import org.glassfish.openesb.api.service.ServiceMessageFactory;
import org.glassfish.openesb.api.service.ServiceProvider;



public class MyProvider implements  ServiceProvider {
   
    ServiceMessageFactory msgFactory_;
   
    public ServiceMessage invoke(ServiceMessage message) throws Exception {
        // Print out the content of the message
        String payload = (String)message.getPayload();
        System.out.println(payload);
       
        // One way exchange, so there's no need to return anything
        return null;
    }


    public void setMessageFactory(ServiceMessageFactory factory) {
        msgFactory_ = factory;
    }
   
    public void setAnotherBean (AnotherBeanI bean){
     //make use the bean
    }


}  


Define the spring beans in the spring config file bundle-context.xml 




<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> 
       <bean name="anotherBean" class="org.foo.AnotherBeanImpl" />
       <bean name="fujiService" class="org.foo.MyProvider">
         <property name="anotherBean" ref="anotherBean"/>
       </bean>
      
</beans> 


Let us define the beans to be exported as OSGI service, Once the bean MyProvider is exported as osgi service,  any JBI component will be able to access this bean by sending a normalized Message see simple service api for more details 




<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns:beans="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://www.springframework.org/schema/osgi"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                      http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi.xsd"> 


 <service id="fujiServiceOsgi" ref="fujiService"
  interface="org.glassfish.openesb.api.service.ServiceProvider">


  <service-properties>
   <beans:entry key="org.glassfish.openesb.serviceName" value="abcService" />
   <beans:entry key="org.glassfish.openesb.endpointName" value="endpoint1" />
  </service-properties>
 </service>


</beans:beans>




Based on the osgi service with the ServiceProvider Interface, an jbi  internal interpoint is activated, The activation of the endpoint is based on the osgi service properties as specified in the bean service definition shown above



  • org.glassfish.openesb.serviceName is used for the service name of the activated endpoint

  • org.glassfish.openesb.endpointName is used for the endpoint name of the activated endpoint


Install the springDM bundles into Fuji-Felix



In order to use springDM application one has to install all the required spring DM osgi bundles, see the set of osgi bundles which needs to installed and started, more details



Build and deploy the application




Go to the project folder and execute
  mvn clean build
In the felix console type install and start the springDM bundle just created
  install file:/...path_to_springDM_bundle..........org.foo.springdm.fuji-1.0.jar 


Invoking JBI-Endpoint from a spring application 



This would require a springDM application to import an osgi service registered by the Fuji/jbi runtime. Note the current Fuji implementation while activating an jbi endpoint , register an osgi service based on the endpoint properties, The endpoint properties are once again based on service name and the endpoint name, Assuming and endpoint had been activated by a JBI component with service-name = xyzService and endpoint-name=xyzEndpoint , how such a endpoint can be accessed from an spring application. In the diagram below the service consumer is part of the spring application .



 


 1. Import the osgi services, using the spring-osgi-config file, note the filter




<reference id="jbiService"
  interface="org.glassfish.openesb.api.service.ServiceConsumer"
  filter="(org.glassfish.openesb.serviceName=xyzService)"  />


2. Use dependency injection to set the service reference into a bean




<bean id="someBean" class="org.foo.BeanWithJbiServiceReference" lazy-init="false">
  <property name="serviceReference" ref="jbiService" />
  <property name="service" ref="jbiService" />
</bean>


3. Define the bean and Invoke




package org.foo;
import org.glassfish.openesb.api.service.ServiceConsumer;
import org.glassfish.openesb.api.service.ServiceMessage;
import org.osgi.framework.ServiceReference;


public class BeanWithJbiServiceReference {
  private ServiceReference serviceReference;
  private ServiceConsumer service
  public void setServiceReference(ServiceReference serviceReference) {
   this.serviceReference = serviceReference;
  } 
  public void setService(ServiceConsumer service) {
   this.service = service;
  } 
  public void invokeJBIService(Object payload) throws Exception{
   ServiceMessage message = service.getServiceMessageFactory().createMessage();
   message.setPayload(payload);  
   service.invoke(message);
  } 
}
 



Future Direction Idea is to provide capabilty which will let any spring bean or osgi service to be accessed seamlessly, based on service properties or configuration, Also Fuji going forward will provide native support for spring beans . Read On   

Wednesday Aug 19, 2009

Soap over jms

W3C has recently released W3C Candidate Recommendation for soap over jms, http://www.w3.org/TR/soapjms/


The above document specifies how SOAP should bind to a messaging system that supports the Java Message Service. Binding is specified for both SOAP 1.1 and SOAP 1.2.



What does this bring to the table?



  • The primary objective is to ensure interoperability between the implementations of different Web services vendors

  • Also some providers of Web services use intermediary services such as routing gateways; or SOAP/HTTP to SOAP/JMS gateways, they will be interested in the standards

  • Reliable way of delivering soap message



Can interoperabilty be an issue here?


Binding soap to JMS leave the other platforms which are not based on java


Note some of the existing capabilty which some of the vendors offer


Friday Jul 31, 2009

JMSJCA Interceptors

This is a new feature which has been recently added to JMSJCA,



 


Where can an application apply this interceptors?


1. While using MDB, or even while sending out JMS message in an JAVAEE Application, how to use? more info


2. While using Composite Application involving JMSBC , see more info

Monday May 11, 2009

Asynchronous Webservice

Asynchronous Webservice Client: Client side asynchrony can be achieved using the following,



  1. Async Polling

  2. Async Callback-handler


1. Create a Calculator Application using the examples which comes with glassfishesb/netbeans


 calculator app


2.  Observe the webservice client for the above, note the webservice interface has a single operation which is by default a synchronous call, we will see how to generate the interface which makes the same call in an asynchronous way



3. Enable Asynchronous Client : note the interface now has two more operations


enable asyn client


4. How to invoke using the above generated service endpoint interface ,


Async Polling


The client application will invoke the async polling operation on the stub and check for a response on the Response object. The response is available when Response.isDone returns true.



javax.xml.ws.Response<com.sun.CalculateResponse> resp = port.calculateAsync(x, y);
 while(!resp.isDone()) {
  // do something


}
System.out.println("Result = "+resp.get().getReturn());
 



Async CallbackHandler


In this case the  client application has to provide an AsyncHandler by implementing the javax.xml.ws.AsyncHandler<T> interface.



// Async callback handler


class CalculatorWSCallbackHandler implements javax.xml.ws.AsyncHandler<com.sun.CalculateResponse> {
    private com.sun.CalculateResponse output;


    public void handleResponse(javax.xml.ws.Response<com.sun.CalculateResponse> response) {
        try {
            output = response.get();
        } catch(Exception ex) {
            // handle exception
        }
    }


    com.sun.CalculateResponse getResponse() {
         return output;
    }
}


// The async handler is then passed as a parameter of the async callback method:


CalculatorWSCallbackHandler asyncHandler = new CalculatorWSCallbackHandler();
 // process asynchronous response here
 java.util.concurrent.Future<? extends java.lang.Object> result = port.calculateAsync(x, y, asyncHandler);
 while(!result.isDone()) {
  // do something
 }
 out.println("Result = "+asyncHandler.getResponse().getReturn());
  



5. Using the Dispatch Api


Four types of MEP are supported using the dispatch API



  • Object response = dispatch.invoke(T);

  • dispatch.invokeOneway(T);

  • Response<T> response = dispatch.invokeAsync(T);

  • Future<?> response = dispatch.invokeAsync(T, AsyncHandler);



The example shows how the asynchronous invocation can be made while using the SOAPMessage

Aysnc Polling



Response<SOAPMessage> res = dispatch.invokeAsync(soapMessage);
 while (!res.isDone()) {
     //do some work
 }
 SOAPMessage soapM = res.get();



Async CallbackHandler



class ResponseHandler implements javax.xml.ws.AsyncHandler<SOAPMessage> {



 SOAPMessage output = null;


 public void handleResponse(Response<SOAPMessage> arg0) {
     try {
  output = arg0.get();
     } catch (Exception e) {
  // handle exception
     }
 }
 SOAPMessage getResponse() {
     return output;
 }
      }
 



 ResponseHandler rhandler = new ResponseHandler();
 Future<? extends java.lang.Object> f = dispatch.invokeAsync(message, rhandler);
 while(!f.isDone()){
     //do some work
 }
 
 SOAPMessage m = rhandler.getResponse();



Using WS-Addressing


WS-addressing supports asynchronous MEP , here is one example taken from the specification, Note the replyTo part of the Request message, Any service implementing ws-addressing specification will send the response message based on the replyTo Message addresing property



Request 



<S:Envelope
  <wsa:MessageID>abc</wsa:MessageID>
    <wsa:ReplyTo>
    <wsa:Address>http://abc.com/client1</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To S:mustUnderstand="1">http://fabrikam123.example</wsa:To>
    <wsa:Action>http://fabrikam123.example/mail/Delete</wsa:Action>
  </S:Header>
  <S:Body>
    <f123:Delete>    
       <maxCount>42</maxCount>
    </f123:Delete>
  </S:Body>
</S:Envelope>



Response



<S:Envelope
    <wsa:MessageID>xyz</wsa:MessageID>
    <wsa:RelatesTo>abc</wsa:RelatesTo>
    <wsa:To S:mustUnderstand="1">
     
http://abc.com/client1
    </wsa:To>
    <wsa:Action>http://fabrikam123.example/mail/DeleteAck</wsa:Action>
  </S:Header>
  <S:Body>
    <f123:DeleteAck/>
  </S:Body>
</S:Envelope>




 


The diagram below shows the flow  of messages


ws-addressing


Note: if replyTo contains an anonymous URI


http://schemas.xmlsoap.org/ws/2003/03/addressing/role/anonymous



When an application/client uses anonymous URI, it says that there is no real endpoint available for this address. Using the anonymous URI is equivalent to not using the ReplyTo header, the response must flow back in the HTTP response message. The web-service must be able to dynamically switch between synchronous and asynchronous modes on the basis of replyTo or faultTo headers.


 


More info



  1. Async Client

  2. WS-Addressing

Wednesday Apr 29, 2009

Jms Messaging Bridge


What is a jms Bridge?


A messaging bridge consists of two destinations that are being bridged: a Source destination that the bridge reads messages from and a Target destination where the bridge sends the messages that it receives from the source destination. Many of the jms provider provide the jms bridge capabilty. However it is also easy to build a custom JMSbridge using JMSJCA



Building jms bridge using java or Composite Application


1. Using standalone java application


JMSJCA support connecting to various JMS Providers like Sun Java Message Queue, JBossMQ, Websphere Message Queue or MQSeries, Weblogic JMS Server, JMS Grid, STCMS. So if one want to build bridge which does not require support for XA transaction. One can easily use the JMSJCA as library  for the purpose as it provide a unified interface for accessing the JMS Providers. The diagram below shows the flow of message.



 


2. Using javaee container


However one may like to make the bridge more reliable. and like to treat the receiving of messages from the source and delivering the same to the target as atomic, i.e want the bridge to support XA transaction, then it will ideal to use javaee container for that purpose, We will show a sample piece of pseudo code which use MDB to build a bridge.


More Info on How to create a MDB and jms Message Producer using JMSJCA in glassfish is available here


Lets say that the requirement is to build a bridge for Sun-Java-Message-Queue to Websphere-Message-Queue , One can use the following logic in the MDB


public void onMessage(Message sunJavaMessage){


     //sunJavaMessage is the received message from Sun Java MQ ,



  1.  Create a producer, for say Websphere Message Queue(WMQ)

  2.  Transform message Header, Properties, Body from  SunJava-MQ to WMQ message

  3.  Send the message


}


Note that the step 2 , is the crucial step which one need to implement. While implementing the Message Conventer one has to take care of the following



  • iterate over jms Message Properties, copy from source to destination

  • handle vender specific properties, i.e properties starting with JMS_

  • copy message Body, note Text, Map, Byte,Object, Stream Message needs to handled seperately

  • copy relevant jms headers (like jms type, correlationId, timestamp, priority, expiration etc)


Some of the advantages of using a javaee container along with JMSJCA are



  • The ejb(mdb) container takes care of the reliable delivery

  • One can have a scalable messaging bridge

  • Resource Management, Connection pooling , MDB Instance pooling is done by the container

  • In case of a crash, the appServer/ejb container takes care of recovery

  • leverage the JMSJCA monitoring capabilty

  • redelivery handling

  • JMSJCA message wrapping


3. Building jms bridge using Composite Application


Idea is, Can we build a jms messaging bridge without any java-code , One can create a composite application which uses jmsbc-->bpel-->jmsbc . Note One limitation of building a bridge using jmsbc is that not all the jms message type is supported by jmsbc, Only supported Message are TextMessage, BytesMessage and MapMessage. Also if one require to convert all the message Header , Properties from source to destination , then one has to create a more involved wsdl. More info on creating composite applications using  JMSBC and BPEL. The diagram below shows the flow of message.



step a) Create a CompositeApp using jmsbc-->bpel-->jmsbc 


  


step b) Use the bpel mapper to map message properties , header and body


Use the bpel mapper to copy the message headers, properties and body, Note this takes care of only part of the message conversation, However one can always specify the message parts which maps to other message properties, see the link for more info



More info on Messaging Bridge and their JMS provider



  1. Weblogic Messaging Bridge

  2. Sun Java Message Queue

  3. Jboss Messaging Bridge

  4. ActiveMQ bridge

  5. SoniqMQ Bridge

Tuesday Mar 03, 2009

WS-Addressing and stateful webservice

 


WS-addressing and its use



  • Provides transport-neutral mechanisms to address Web services and messages.

  • Stateful webservice, Web services are usually stateless, , however it is possible to enable webservice to be stateful i.e. to share multiple instances of service endpoints between subsequent invocation.

  • Simple and complex Message Exchange Patterns

  • Used for other WS-\* specification like reliable Messaging, WS-MetadataExchange, WS-Security


WS-Addressing and stateful webservice


We will dive in details how stateful sebservice is created? how a client can access the same? and how metro/jax-ws maintain the state in between subsequent invocation?, We will make use of the examples which comes with metro/jax-ws RI


Examples 



Server (Book.java and BookStore.java)



@Stateful @WebService @Addressing
public class Book {
    private final String id;
    private volatile List<String> reviews = new ArrayList<String>();
    public Book(String id) {
        this.id = id;
    }
    public String getId() {
        return id;
    }
    public synchronized void postReview(String review) {
        List<String> l = new ArrayList<String>(reviews);
        l.add(review);
        reviews = l;
    }
    public List<String> getReviews() {
        return reviews;
    }
    public boolean equals(Object that) {
        if (that == null || this.getClass() != that.getClass()) return false;
        return this.id.equals(((Book)that).id);
    }
    public int hashCode() {
        return id.hashCode();
    }


    public static StatefulWebServiceManager<Book> manager;
}



@WebService
public class BookStore {
    public W3CEndpointReference getProduct(String id) {
        return Book.manager.export(new Book(id));
    }
}
 




See the Book.java which is stateful webservice, this is done by declaring Stateful annotation on a Book.java class. Note the class also have a public static method/field that takes StatefulWebServiceManager. Once the service is deployed the jax-ws does the resource injection on the field or the method. A stateful web service (Book.java) does not need to have a default constructor. Most of the time user would to define a constructor that takes some arguments, so that each instance carries certain state. Each instance of a stateful web service( Book.java) is identified by an unique EndpointReference. BookStore.java creates an instance of a class, JAX-WS RI assign a unique EPR for the instance as follows   Book.manager.export(new Book(id))



Client
        BookStore bookstore = new BookStoreService().getBookStorePort();
        BookService service = new BookService();


        1. Book book1 = service.getPort(bookstore.getProduct("abc001"), Book.class);
        2.  book1.getId();
        3. book1.postReview("This book is great!");
        4. book1.getReviews();


        similar code for book2....




Once the client runtime receives the EPR info , it uses the EPR info in the subsequent call, i.e When client send messages to this EPR, the JAX-WS RI makes sure that the particular exported instance associated with that EPR will receive a service invocation. We will see shortly how this is achieved


 


Digging Deeper 


We will trace the soap request response for the client code (line 1, 2, and 3). This will give an clear idea how an Endpoint can associate the request with an exported instance of an EPR, and how the exported instance is  identified using an unique Identifier. 


1. Invoke BookStore service( bookstore.getProduct("abc001")) , Note the soap request-response, The response contain the EPR details which contains the address and the unique <jaxws:objectid>, note this objectid is used in subsequent call to the BookService, and this how the jaxws RI find out which instance of the EPR will get the invocation




get endpoint reference 



2. book1.getId(); note the soap request, here the jax-ws inserts the required addressing headers and the <jaxws:objectid>,  





get id of the book 






3.  book1.postReview("This book is great!"); note the soap request, here also the jax-ws inserts the required addressing headers and the <jaxws:objectid>,  





post review of the book



 





 More Info



 


 

Wednesday Feb 25, 2009

Message Queue in the Cloud

While Cloud computing is stretching the Imagination



of the technology community , one of the interesting area  is "Message Queue in the Cloud"


 


Message Queue in the cloud


Here are few of players who are taking a lead in the "Message Queue in the Cloud" 



 


 

Tuesday Feb 24, 2009

WS-SecureConversation, Improve performance of your Webservice

Public key cryptography


WS-Security make extensive use of the public key cryptography. Public key cryptography(asymmetric key) is computationally more expensive than symmetric key cryptographic, see the following link for more  info, so the solution is to make use of combination of asymmetric and symmetric key cryptography.  


WS-SecureConversation


While message authentication is useful for simple or one-way messages, parties that wish to exchange multiple messages typically establish a secure security context in which to exchange multiple messages. A security context is shared among the communicating parties for the lifetime of a communications session. Once the context and secret have been established (authenticated), Derived Keys can be used for signing and encryption of the messages. Some of features of ws-secureconversation are



  • similar to SSL

  • create a security context

  • message processing is  much faster at both client and webservice endpoint

  • transparent to the user 


 



 Esstablishing Security Context


A security context needs to be created and shared by the communicating parties before being used. This is done by creatring a Security Context Token(SCT). The specification defines three different ways of establishing a security context among the parties of a secure communication.



  • SCT created by a  STS(security token service)

  • SCT created by one of the communicating parties and propagated with a message

  • SCT created through negotiation/exchanges


WS-Secure Conversation is built on top of two other web services specifications, they are WS-Security and WS-Trust. In metro/wsit each web service enabled for WS-SecureConversation has an associated STS that is used to issue and manage security contexts


To request a Security Context Token(SCT) , an RequestSecurityToken(RST) is sent to the webservice endpoint which is setup using secure conversation , the request is transparently routed to the trust service which responds with a RequestSecurityTokenResponse , the response is send back to the client, Note the sample below also show DerivedKeyToken, we will talk about derived keys in a moment.


 Sample SecurityContextToken and DerivedKeyToken



 <wsc:SecurityContextToken
                xmlns:ns17="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
                xmlns:ns16="http://www.w3.org/2003/05/soap-envelope"
                wsu:Id="uuid-4063ae9b-fe66-4e09-a5fb-8fda903f34d8">
    <wsc:Identifier>urn:uuid:e4a2619f-cb5c-45ec-b5db-c931db3db789</wsc:Identifier>
</wsc:SecurityContextToken>



<wsc:DerivedKeyToken

                xmlns:ns17="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
                xmlns:ns16="http://www.w3.org/2003/05/soap-envelope" wsu:Id="_3">
    <wsse:SecurityTokenReference wsu:Id="_5002">
        <wsse:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct" URI="#uuid-4063ae9b-fe66-4e09-a5fb-8fda903f34d8" />
    </wsse:SecurityTokenReference>
    <wsc:Offset>0</wsc:Offset>
    <wsc:Length>16</wsc:Length>
    <wsc:Nonce>Kq/1ptgjZpX2g1q6MiJcSfTX</wsc:Nonce>
</wsc:DerivedKeyToken>


 



note the element /wsc:SecurityContextToken/wsc:Identifier This required element identifies the security context using an absolute URI. Each security context URI MUST be unique to both the sender and recipient. It is RECOMMENDED that the value be globally unique in time and space 


Derived Keys  


A security context token implies or contains a shared secret. This secret MAY be used for signing and/or encrypting messages, but it is RECOMMENDED that derived keys be used for signing and encrypting messages associated only with the security context


Using a common secret, parties may define different key derivations to use. For example, four keys may be derived so that two parties can sign and encrypt using separate keys. In order to keep the keys fresh (prevent providing too much data for analysis), subsequent derivations may be used 


 how the derived keys are used


 


How Keys are derived? 


A subset of the mechanism defined for TLS in RFC 2246. Specifically, P_SHA-1 function is used to generate a sequence of bytes that can be used to generate security keys. the algorithm is refered to as:



http://schemas.xmlsoap.org/ws/2004/04/security/sc/dk/p_sha1



This function is used with three values – secret, label, and seed. The secret is the shared secret that is exchanged (note that if two secrets were securely exchanged, possible as part of an initial exchange, they are concatenated in the order they were sent/received).Secrets are processed as octets representing their binary value (value prior to encoding). The label is the concatenation of the client's label and the service's label. These labels can be discovered in each party's policy (or specifically within a <wsc:DerivedKeyToken> token). Labels are processed as UTF-8 encoded octets. If either isn't specified in the policy, then a default value of "WS-SecureConversation" (represented as UTF-8 octets) is used. The seed is the concatenation of nonce values (if multiple were exchanged) that were exchanged (initiator + receiver). The nonce is processed as a binary octet sequence (the value prior to base64 encoding). The nonce seed is required, and MUST be generated by one or more of the communicating parties.The P_SHA-1 function has two parameters – secret and value. The label and the seed is concatenated to create the value. That is:



P_SHA1 (secret, label + seed)


Syntax For Derived Keys


<DerivedKeyToken wsu:Id="..." Algorithm="...">
    <wsse:SecurityTokenReference>...</wsse:SecurityTokenReference>
    <Properties>...</Properties>
    <Generation>...</Generation>
    <Offset>...</Offset>
    <Length>...</Length>
    <Label>...</Label>
    <Nonce>...</Nonce>
</DerivedKeyToken>


 


for more details for each of the element see the specification
 


How To Configure in Composite Application/WSIT editor


GlasfishESB , metro support the following security profiles, chose one of the security profile in the CASA editor and then configure for secure-conversation



  • Username Authentication with Symmetric Keys

  • Mutual Certificates Security

  • Transport Security (SSL)

  • Message Authentication over SSL

  • SAML Authorization over SSL

  • Endorsing Certificate

  • SAML Sender Vouches with Certificates

  • SAML Holder of Key

  • STS Issued Token

  • STS Issued Token with Service Certificate

  • STS Issued Endorsing Token


how to configure

Thursday Feb 12, 2009

Mtom, Soap with Attachment in Composite Applications

Mtom is used to optimize the transmission of soap message over the wire. MTOM uses a  wire format of a SOAP message by selectively encoding portions of the message, whilst still presenting an XML Infoset to the SOAP application. Optimization is available only for element content that is in a canonical lexical representation of the xs:base64Binary data type  


This article talks how to use mtom in glassfish esb, what are the limitation current implementation has , how to overcome the same

[Read More]

Thursday Feb 05, 2009

Soap1.2 in GlassfishESB

This article show how to use soap1.2 in glassfishesb or javacaps or openesb, also talks about some of the point to note in terms of changes or the differences with soap1.1 

[Read More]

Friday Jul 11, 2008

Security in open-esb

Basic Authentication, this can be based on 

1. Glassfish security realm
2. Sun Java Access Manager
3. WssTokenCompare

 The following steps describes the basic authentication process

  • The client sends a request to the Web service, sending the  credentials as part of the http authorization header , base64 encoded.
  • The Web service validates the credentials against the glassfish/access-manager /WssTokenCompare.
  • The Web service returns a response to the client.

 For more information see basic authentication

Basic Authentication and Authorization

1. this support is only available while using Sun Java System Access Manager while doing basic authentication for more detail see

Brokered Authentication  


The brokered authentication has the following steps

  • The client submits an authentication request
  • The authentication broker validate the authentication credentials , The authentication broker responds to the client if authentication is successful and issues a security token. The client can use the security token to authenticate with the service.
  • A request message containing the security token is sent to the service.
  • The service authenticates the request by validating the security token and sent the response

In open-esb this is achieved using wsit , and the most common security mechanism used in this regard are

  •  X509 Security token
  • Security Token Service

Fore more details see the following examples



Monday Apr 09, 2007

Soa Usage Governance and jbi

Soa governance is a very broad topic. This blog focus on the SOA Usage governance and how can we implement Usage governance in open-esb and jbi. see Soa Governance for sun soa governance solution.

When we talk about SOA Usage governance some of the questions that come up are:

  1. Are we using any usage metrics to for our services?
  2. Are we tracking the messages that are flowing through the system?
  3. Who has / can access a particular service (both internal and external)?

The common approach that the software vendors use is the interception or the mediation. The interception mechanism can be used for various purposes like filter, aggregation, content based routing, transformation, QOS and SLA

The strategies used to resolve Usage governance are

  • Lease Management
  • Charge back
  • Access Control
  • Monitoring
  • Message Tracking
  • Prioritization ...etc

In JBI environment we can use either of the following strategy to mediate or intercept message.

a) NMR interceptor: The JBI spec ( possibly this feature will be included in JBI 2.0 ) provide the user with API to implement an interceptor/handler and use that to intercept message for a given JBI component.

b) Aspect Oriented Programming: In this approach the interception or mediation is done using a service engine called Aspect Service Engine.

The diagram above shows a request-response scenario. Both the request message and the response message is intercepted / mediated using a aspect service engine.

The idea is to inject one or more aspect in between a consumer and provider. The Aspect oriented approach is granular than the NMR interceptor approach and hence more powerful in certain cases. Here the user can be selective about applying aspect for specific service endpoint for a given JBI component. To know more about aspect oriented programming see

  1. Aspect Oriented Programming in JBI
  2. Aspect Service Engine

The diagram above shows the flow of message between Service Units of various service engine and Binding Components and the Aspect Service Unit.This basically shows how we can inject a set a aspect between a consumer and provider. Note each of this aspect for given SU are configurable during runtime.

Monday Apr 02, 2007

Using Aspect Service Engine for Auto-Reconnect

Let us a consider a simple composite App where BPEL Service Consumes a simple "HelloService". It might happen that the service may be down for certain period of time. How does the Composite Application manage to live with such issues?

The Aspect Service Engine can be very useful to solve such problem. To know more about aspect oriented programming in JBI and Aspect Service Engine see the following links

  1. Aspect Oriented Programming in JBI
  2. Aspect Service Engine

In Short the Aspect Oriented programming in JBI tries to solve some of the cross-cutting concerns. Some examples of such cross-cutting concerns are throttling which throttles the number of message going through some subsystems, jbi component or to particular webservice, or caching which cross-cuts all cached objects, or alerting, or message tracking, or auto-reconnect, or queuing, et al. The cross-cutting concern which we are trying to show case is auto-reconnect.

The above diagram shows how we can inject or weave a Auto-Reconnect aspect in between the BPEL Service Engine and the external web service. The Auto-Reconnect aspect is responsible for doing a reconnect if the HelloService is down for some period of time. The number of times the Auto-Reconnect aspect is going to do a retry and the interval between each retry is configurable. Now what does this achieve?

The BPEL Service Engine or the consuming client now does not have to care about whether a particular service is down for a brief period of time. It does not have to put some business logic to handle such issues as this can taken care by injecting Auto-Reconnect aspect as we have seen in the above diagram.

About

sujit

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today