Examples of WS-Security using CXF and WSS4J

If you are searching for some simple examples to understand and write WS-Security stuff (UsernameToken, Timestamp, Signature or Encryption) actions. I filed a jira task on JIRA, made some examples and Dan committed them in the svn. You can get them in CXF 2.2.3 distribution.
You can check the following (all included Timestamp action):

• UsernameToken
• UsernameToken and Signature
• UsernameToken, Signature and Encryption

To get more detailed description about how it all works you can read this Configuring CXF for WS-Security... . I hope your initial queries, doubts while creating and understanding startup examples of WS-Security using CXF and WSS4J will be answered there :)

Specifying WS-SecurityPolicy, RM, Policy in a WSDL file

WS-Policy provides a way for the provider of a web service to convey conditions under which it provides the service. A invoker might use this policy to decide whether to use or not to use the service.WS-Policy just gives basic assertion support like, <wsp:all></wsp:all>, <wsp:exactlyone></wsp:exactlyone>to express one set of policy or alternatives too. Any conditions/requirements as assertions under <wsp:all></wsp:all>become mandatory,where as assertions inside <wsp:exactlyone></wsp:exactlyone>are considered as alternatives to each other.You can read more about various combinations/interactions/alternative in OASIS WS-PolicySpecification[1].

• You can specify these WS-Poilcy assertions either inside input , output,fault, operation, port, or in binding wsdl elements.
• You can either put them directly as child elements of them, or else you can refer them using <wsp:PolicyReference> element.

Policy can be attached as described by WS-PolicyAttached [4] at following levels:

• Service Level: {Applied at <wsdl:Service>} - A policy associated with a service policy subject applies to any message exchange using any of the endpoints offered by that service.

• Endpoint Level: {Applied at <wsdl:port> or <wsdl:portType> or <wsdl:binding>} - Since <wsdl:portType> can be used with multiple Bindings, hence it is RECOMMENDED to specify only abstract policy (binding independent) at this <wsdl:portType>. I prefer to use the other two options <wsdl:port> or <wsdl:binding> to apply endpoint policy. Policies associated with an endpoint policy subject apply to any message exchange made using that endpoint.

• Operation Level: {Applied at <wsdl:portType/wsdl:operation> or <wsdl:binding/wsdl:operation>} - Policies associated with an operation policy subject apply to the message exchange described by that operation. Again, it is RECOMMENDED to specify only abstract policy at <wsdl:portType/wsdl:operation>, hence <wsdl:binding/wsdl:operation> is a prefered place to specify operation level policies.

• Message Level: {Applied at <wsdl:message> or <wsdl:portType/wsdl:operation/wsdl:input> or <wsdl:portType/wsdl:operation/wsdl:output> or <wsdl:portType/wsdl:operation/wsdl:fault> or <wsdl:binding/wsdl:operation/wsdl:input> or <wsdl:binding/wsdl:operation/wsdl:output> or <wsdl:binding/wsdl:operation/wsdl:fault>} - Policies associated with a message policy subject apply to that message (i.e. input, output or fault message).

WS-Security Policy [2], WS-RM [3] assertions are build on top of WS-Policy for specifying security or reliable messaging requirements/constraints for aservice. For example, specifying security requirements for outgoing message, I can write as,

<wsp:Policy wsu:Id="Output_Policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsu:Timestamp/>
</sp:EncryptedParts>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>


and I can refer this policy as,

<wsdl:binding name="WebTransactionServiceSoapBinding"
type="tns:CreditCard">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<!--wsp:PolicyReference URI="#Endpoint_Policy"/-->
<wsdl:operation name="purchase">
<soap:operation soapAction="" style="document"/>
<wsdl:input name="purchase">
<!--wsp:PolicyReference URI="#Input_Policy"/-->
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output name="purchaseResponse">
<wsp:PolicyReference URI="#Output_Policy"/>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>

or specifying RM assertions as Embedded instead of referred can be,

<wsdl:service name="CartSLSBBeanService">
<wsdl:port binding="ns1:CartSLSBBeanServiceSoapBinding"
name="CartSLSBBeanPort">
<wswa:UsingAddressing
xmlns:wswa="http://www.w3.org/2005/02/addressing/wsdl"/>
<soap:address location=" http://localhost:8181/cart/cart"/>
<wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
xmlns:wsu="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="RM">
<wsam:Addressing
xmlns:wsam=http://www.w3.org/2007/02/addressing/metadata>
<wsrmp:RMAssertion
xmlns:wsrmp=http://schemas.xmlsoap.org/ws/2005/02/rm/policy>
<wsrmp:BaseRetransmissionInterval Milliseconds="10000"/>
</wsrmp:RMAssertion>
</wsp:Policy>
</wsdl:port>
</wsdl:service>

You can read more about WS-SecurityPolicy[2] and WS RM[3] so as to understand what these assertions actually specify.I hope this helps
[1]. http://www.w3.org/TR/ws-policy/
[2]. http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html
[3].http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-spec-cd-04.html
[4]. http://www.w3.org/TR/ws-policy-attach/

Understanding WS-Trust and configuration in CXF

Apache CXF is a high-performance, extensible, Intuitive & Easy to Use open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS. CXF supports a variety of web service standards including SOAP, the Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, and WS-Security.

Apache CXF 2.2 is the third major release of CXF project. I found this release very interesting as it supports WS-SecurityPolicy and Partially supports WS-Trust. WS-Trust specifically deals with the issuing, renewing, and validating of security tokens, as well as with ways to establish, assess the presence of, and broker trust relationships between participants in a secure message exchange.

WS-SecurityPolicy is a very helpful and easier way of specifying your security requirements in an interoperable way. You can access a secured web service hosted on MS server by just pointing to the wsdl containing embedded WS-SecurityPolicy or a WS-Policy reference to a separate WS-SecurityPolicy file.

In CXF-2.2, WS-Trust is supported on client side, that means that now you can access a web services hosted by any WS vendor who requires you to produce tokens for authentication and authorization. For example, if I host a web service in Metro and configures a Metro STS (Secure Token Service - which provides tokens to clients). My CXF client will talk to Metro STS to acquire a token, once acquired CXF client can then produce this token to the Metro Service as an authentication and authorization token. An STS itself is a web service - a web service that issues security tokens.

Daniel Kulp has done a great job in making WS-Trust support up and working. In future release of CXF, we will come up with full support for WS-Trust. Any one who is interested can join the development I have filed a jira task for it.

How WS-Trust works: Basically on client side, ws-policy engine while parsing and understanding service wsdl, from <issuedtoken><issuer>... <issuer>assertion it learns that the service requires a security token to be produced. gives the WS-Addressing address of the STS service and WS-MEX (Metadata Exchange) address for getting the WSDL location of STS. STS may confirm the authenticity of the client who is requesting for the token. Based on the satisfactory confirmation of the authentication of the client, <issuedtoken> may have an assertion <requestsecuritytokentemplate> in which the service may specify what kind of RST request a client should make to STS, a service may specify it's particular requirements for the Token to be produced to it, the requirements can be KeySize, KeyType, TokenType, etc.

STS issues a RSTR (RequestSecurityTokenResponse) which contains requestedToken and proofkey. A proof key indicates proof of possession of the token associated with the requested security token. There are two types of proof keys: symmetric or asymmetric. A service can specify the proof key in the <keytype> element of <requestsecuritytokentemplate>.

In case of Symmetric key, STS creates and distributes the Symmetric key to both service and client. STS gives the key to the client in the <requestedprooftoken> element. STS gives the exact copy of the key to the service in the <keyinfo> element of the <subjectconfirmation> element in the issued SAML assertion in the RSTR response to the client. Client then forward the issued SAML assertion to the service.

In case of Public Key, client doesn't want to trust STS for issuing the secret key as proof of possession. In the RST (RequestSecurityToken) message client supplies RSA key or X.509 public key to STS. STS just embeds the RSA key or X.509 public key certificate in the <keyinfo> element of the <subjectconfirmation> element in the issued SAML assertion in the RSTR response to the client. Client then forward the issued SAML assertion to the service.

In case of No Proof Key, the issued token in <requestedsecuritytoken> itself works as proof of possession.

After getting RSTR, client composes the web service request as requested by WSDL requirements of the service. It embeds the SAML assertion into the request message to the service. Service and client uses the proof key for authentication and authorization of messages afterwards.

Configuring CXF for WS-Trust

Since currently only Client side support is provided in CXF 2.2 version (as I have discussed at the start of this blog entry), all we require to do is to configure a STSClient java class, org.apache.cxf.ws.security.trust.STSClient with the properties to wsdl location, service name, endpoint name. STSClient will look into wsdl, request for an issue, validate, renewal of the required token from STS and will put into the context of WS call so that finally the ws-request can be send with the required token, proof token and SAML assertion. Usually, you configure STS client in either of below two ways,

You can configure STSClient using code-first by creating a new instance of STSClient and calling setter methods of STSClient and finally setting a property "ws-security.sts.client" oof RequestContext() method on port instance as,

((BindingProvider)port).getRequestContext().put("ws-security.sts.client", stsinstance);

or, else you can configure spring bean as,

<jaxws:client name="{http://cxf.apache.org/}MyService">

<jaxws:properties>

<entry key="ws-security.sts.client">

<!-- direct STSClient config and creation -->

<bean class="org.apache.cxf.ws.security.trust.STSClient">

<constructor-arg ref="cxf"/>

<property name="wsdlLocation" value="target/wsdl/trust.wsdl"/>

<property name="serviceName" value="{http://cxf.apache.org/securitytokenservice}SecurityTokenService"/>

<property name="endpointName" value=""{http://cxf.apache.org/securitytokenservice}SecurityTokenEndpoint"/>

<property name="properties">

<map>

<entry key="ws-security.username" value="joe"/>

<entry key="ws-security.callback-handler" value="interop.client.KeystorePasswordCallback"/>

<entry key="ws-security.signature.properties" value="etc/alice.properties"/>

<entry key="ws-security.encryption.properties" value="etc/bob.properties"/> </map>

</property>

</bean>

</entry>

</jaxws:properties>

</jaxws:client>

Sample Annotation

A Novice Program for writing own Annotation. Annotations are not rocket science, they just have retention policy (runtime, source, class) and target (field, method, class, type, parameter) and finally can be looked using Reflection API.

MyAnnotation.java
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Retention(value = RetentionPolicy.RUNTIME)
@Target(value = { ElementType.FIELD })
public abstract @interface MyAnnotation {
boolean enabled() default true;
String input() default "";
String output() default "";
int value() default -1;
}

Usage.java
import java.lang.reflect.Field;
public class Usage {
@MyAnnotation(input = "Hello")
public int a;
public void myMethod() {
Class<? extends Usage> c = this.getClass(); Field f = null;
try {
f = c.getField("a");
} catch (SecurityException e) { e.printStackTrace();
} catch (NoSuchFieldException e) { e.printStackTrace();
}
MyAnnotation ma = (MyAnnotation) f.getAnnotation(MyAnnotation.class);
System.out.println(ma.input());
}
public static void main(String args[]) {
Usage u = new Usage(); u.myMethod(); }
}

Configuring CXF for Web Service Security using WSS4J

In case you directly want to see samples, you can go to Examples of WS-Security.....
You can read to below to understand bits, assuming you have a sample WS application using CXF. To secure that WS application you need to do following,

Create KeyStores and TrustStores
OpenSSL and Java SE 6 keytool creates X509v3 certificates, whereas Java SE 5 or earlier keytool creates X509v1 certificate. If you already have keystores and truststores and you are not sure about version of them, you can verify the version of your X509 certificate using this blog entry I blogged sometime back. Lets create new keystores and truststores with new X509 private and public key pair.
a) Creating Client Public and Private Key in Client keystore and Server Public and Private key in Server Keystore
keytool -genkey -alias clientX509v1 -keypass keypassword -storetype jks -storepass storepassword -validity 3650 -keyAlg RSA -keystore client-keystore.jks
keytool -genkey -alias serverX509v1 -keypass keypassword -storetype jks -storepass storepassword -validity 3650 -keyAlg RSA -keystore server-keystore.jks
b) Exporting clients public key to an external file and servers public key to an external file
keytool -export -alias clientX509v1 -file client-certfile.csr -keystore client-keystore.jks -storepass storepassword -keyAlg RSA
keytool -export -alias serverX509v1 -file server-certfile.csr -keystore server-keystore.jks -storepass storepassword -keyAlg RSA
c) Import the clients public certificate from the external file to server trust store and servers public certificate to the client trust store
keytool -import -noprompt -alias clientX509v1 -file client-certfile.csr -storepass storepassword -keystore server-truststore.jks -storetype JKS
keytool -import -noprompt -alias serverX509v1 -file server-certfile.csr -storepass storepassword -keystore client-truststore.jks -storetype JKS
Now we have required keystores and truststores with X509V1 certificates.

Configure CXF Bus:
Now we need to configure In and Out configuration of the server and client on CXF using spring. WSS4J provides security implementation for CXF, for security to be applied on XML content, CXF required SAAJ Interceptor which creates the SOAP document over which WSS4J works.

On Client

<jaxws:client
name="{http://apache.org/hello_world_soap_http}TimestampSignEncrypt";
createdFromAPI="true">
<jaxws:features>
<bean class="org.apache.cxf.feature.LoggingFeature"/>
</jaxws:features>

<jaxws:outInterceptors>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor"/>
<ref bean="TimestampSignEncrypt_Request"/>
</jaxws:outInterceptors>

<jaxws:inInterceptors>
<ref bean="TimestampSignEncrypt_Response"/>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
</jaxws:inInterceptors>

</jaxws:client>

On Server

<jaxws:endpoint
name="{http://apache.org/hello_world_soap_http}TimestampSignEncrypt";
createdFromAPI="true">

<jaxws:features>
<bean class="org.apache.cxf.feature.LoggingFeature"/>
</jaxws:features>

<jaxws:outInterceptors>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor"/>
<ref bean="TimestampSignEncrypt_Response"/>
</jaxws:outInterceptors>

<jaxws:inInterceptors>
<ref bean="TimestampSignEncrypt_Request"/>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
</jaxws:inInterceptors>

</jaxws:endpoint>

Above is the CXF Bus configuration on server and client to configure WSS4J, Log an SAAJ interceptors for both in and out configuration.

Provide Security Configuration
Now, we need to write Security configurations on server and client for in and out interceptors.
In this example, I have written all commonly used Actions; using Timestamp, Encrypting method argument, and sigining Timestamp and/or body. The order in which they are written is the order in which these actions are performed. Also, we need to configure user (signature) and encryption user accordingly on server and client. Also, crypto configurations needs to pass about keystore and truststore related information; by signaturePropFile and encryptionPropFile properties.

Below is the security related server side configuration configured in WSS4JInInterceptor and WSS4JOutInterceptor

For Server side outgoing response to Client

<bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor" id="TimestampSignEncrypt_Response">

<constructor-arg>
<map>
<entry key="action" value="Timestamp Signature Encrypt"/>
<entry key="user" value="service"/>
<entry key="signaturePropFile"
value="server_decrypt.properties"/>
<entry key="encryptionPropFile"
value="server_sign.properties"/>
<!--entry key="signatureKeyIdentifier" value="DirectReference"/-->
<!--entry key="encryptionKeyIdentifier" value="IssuerSerial" /-->
<entry key="passwordCallbackClass"
value="com.xyz.ws.security.KeystorePasswordCallback"/>
<entry key="signatureParts"
value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body"/>
<entry key="encryptionParts"
value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://www.w3.org/2000/09/xmldsig#}Signature;{Content}{http://schemas.xmlsoap.org/soap/envelope/}Body"/>
<!--entry key="encryptionKeyTransportAlgorithm"
value="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/-->
<!--entry key="encryptionSymAlgorithm"
value="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/-->
</map>

</constructor-arg>
</bean>

For Server side incoming request from client

<bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor" id="TimestampSignEncrypt_Request">

<constructor-arg>
<map>
<entry key="action" value="Timestamp Signature Encrypt"/>
<entry key="signaturePropFile" value="server_sign.properties"/>
<entry key="decryptionPropFile" value="server_decrypt.properties"/>
<entry key="passwordCallbackClass"
value="com.xyz.ws.security.KeystorePasswordCallback"/>
</map>
</constructor-arg>

</bean>

Below is the client side security related configuration configured in WSS4JInInterceptor and WSS4JOutInterceptor

For Client side outgoing request to Server

<bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor" id="TimestampSignEncrypt_Request">

<constructor-arg>
<map>
<entry key="action" value="Timestamp Signature Encrypt"/>
<entry key="user" value="client"/>
<entry key="encryptionUser" value="service"/>
<entry key="signatureKeyIdentifier" value="DirectReference"/>
<entry key="signaturePropFile" value="client_sign.properties"/>
<entry key="encryptionPropFile" value="client_encrypt.properties"/>
<entry key="encryptionKeyIdentifier" value="IssuerSerial" />
<entry key="passwordCallbackClass"
value="com.xyz.ws.security.KeystorePasswordCallback"/>
<entry key="signatureParts"
value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body"/>
<entry key="encryptionParts"
value="{Element}{http://www.w3.org/2000/09/xmldsig#}Signature;{Content}{http://schemas.xmlsoap.org/soap/envelope/}Body"/>
<!--entry key="encryptionKeyTransportAlgorithm"
value="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/-->
<!--entry key="encryptionSymAlgorithm"
value="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/-->
</map>
</constructor-arg>

</bean>

For Client Side Incoming Response from Server:

<bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"
id="TimestampSignEncrypt_Response">

<constructor-arg>
<map>
<entry key="action" value="Timestamp Signature Encrypt"/>
<entry key="signaturePropFile" value="client_encrypt.properties"/>
<entry key="decryptionPropFile" value="client_sign.properties"/>
<entry key="passwordCallbackClass"
value="com.xyz.ws.security.KeystorePasswordCallback"/>
</map>
</constructor-arg>

</bean>

Contents of crypto configuration files:
You require to give information about the keystore or truststore containing X509 private or public key, keystore password and alias name for the public-private key pair.

For encryption , you require to configure public key of the receiver, hence client/server truststore contains public certificate of server/client alias which is serverx509v1/clientx509v1 respectively.

For Signature, you require to use the private key stored in client/server keystore and hence alias clientx509v1/serverx509v1 respectively.

client_encrypt.properties
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=storepassword
org.apache.ws.security.crypto.merlin.keystore.alias=serverx509v1
org.apache.ws.security.crypto.merlin.file=keystore/client-truststore.jks

client_sign.properties
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=storepassword
org.apache.ws.security.crypto.merlin.keystore.alias=clientx509v1 org.apache.ws.security.crypto.merlin.file=keystore/client-keystore.jks

server_decrypt.properties
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=storepassword org.apache.ws.security.crypto.merlin.keystore.alias=serverx509v1 org.apache.ws.security.crypto.merlin.file=keystore/server-keystore.jks

server_sign.properties
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=storepassword
org.apache.ws.security.crypto.merlin.keystore.alias=clientx509v1 org.apache.ws.security.crypto.merlin.file=keystore/aerver-truststore.jks

Install Bouncy Castle Security Provider
Just check the lib folder of CXF binary distribution as in CXF 2.2 onwards, CXF is having bouncy castle jar, hence no requirement to download this jar if your CXF distribution already have one.

(or else) Download the latest Bouncy Castle provider (bcprov-jdkXX-xxx.jar) for your JDK, then put it in JAVA_HOME/jre/lib/ext.Edit JAVA_HOME/jre/lib/security/java.security. Find the list of security providers:Add the Bouncy Castle provider to the list as,
security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider {assuming 9 entries are there}

Install JCE Unlimited Strength Jurisdiction Policy Files
Due to import control restrictions for some countries, the Java CryptographyExtension (JCE) policy files shipped with the J2SE DevelopmentKit and the J2SE Runtime Environment allow strong but limited cryptography to be used. These files are located at
/lib/security/local_policy.jar
/lib/security/US_export_policy.jar
An unlimited strength version of these files indicating no restrictions on cryptographic strengths is available on the JDK web site for those living in eligible countries.
Unlimited strength Jurisdiction Policy Files may be downloaded from the JavaSoft's web site.Here is the web address:http://java.sun.com/javase/downloads/index.jsp#docs
(At the end of the page under "Other Downloads" section).
Open the readme.txt and follow the instructions:Basically replace two existing jar for the two new ones((US_export_policy.jar and local_policy.jar )

Run your example by passing configuration files we just made

CXF can discover XML configuration files which you have written. For both web service clients and servers, the default location that CXF will look for a configuration for is "/cxf.xml" on the class path.Pass your server and client config files to the Java call to the server and client class as argument
If you wish to override this location, you can specify a command line property: -Dcxf.config.file=some_other_config.xml. This custom configuration file is also expected to be on the class path.
To use a url as the configuration location, specify as follows: -Dcxf.config.file.url=config_file_url
-Dcxf.config.file.url=client.xml
-Dcxf.config.file.url=server.xml

You may get an exception like below:

Caused by: java.io.IOException: exception decrypting data - java.security.Invali dKeyException: Illegal key size at org.bouncycastle.jce.provider.JDKPKCS12KeyStore.cryptData(Unknown Sou rce) at org.bouncycastle.jce.provider.JDKPKCS12KeyStore.engineLoad(Unknown So urce) at java.security.KeyStore.load(KeyStore.java:1185) at org.apache.ws.security.components.crypto.AbstractCrypto.load(Abstract Crypto.java:168) ... 38 more

Don't worry, you just require to put in unlimited strength JCE files in your jdk/jre. Read and follow steps in #Install JCE Unlimited Strength Jurisdiction Policy Files header just above. They will get resolved once you follow steps.

You may get java.security.UnrecoverableKeyException: Cannot recover key - It happens when your storepassword and keypassword are different. Though I think that is a valid case, but as a workaround you can make both passwords the same. Generate the keystores once again, export the certificates and import them into truststore once again. All commands except below two remains the same.

keytool -genkey -alias clientX509v1 -keypass storepassword -storetype jks -storepass storepassword -validity 3650 -keyAlg RSA -keystore client-keystore.jks
keytool -genkey -alias serverX509v1 -keypass storepassword -storetype jks -storepass storepassword -validity 3650 -keyAlg RSA -keystore server-keystore.jks

I hope now you would have seen secured in and out SOAP messages from client and server. :)
Do please let me know if you face some errors, exceptions and also your comments.

XML Schema Validation and importing different encoding schema

Following is a simple code which shows importing an different encoding xml schema into a different encoding xml schema. In the following example Book.xsd imports Age.xsd which has UTF-16 encoding. Following example also shows XML Schema Validation

XMLValidationSample.java
import java.io.IOException;
import org.xml.sax.InputSource;
import org.xml.sax.XMLReader;
import org.xml.sax.SAXException;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
import org.xml.sax.SAXParseException;
import javax.xml.parsers.ParserConfigurationException;
public class XMLValidationSample {
public static void main(String args[]) {
try{
String book = "Book.xsd", first = "first.xsd", last = "last.xsd", age = "age.xsd";
String[] schemas = {book, first, last, age};
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware( true);
factory.setValidating( true);
SAXParser parser = factory.newSAXParser();
parser.setProperty( "http://java.sun.com/xml/jaxp/properties/schemaLanguage",
"http://www.w3.org/2001/XMLSchema");
parser.setProperty( "http://java.sun.com/xml/jaxp/properties/schemaSource",
schemas);
XMLReader reader = parser.getXMLReader();
reader.parse( new InputSource( "Book.xml"));
}catch (SAXException e) {
Exception x = e.getException ();
((x == null) ? e : x).printStackTrace (); }
catch (IOException e) {
e.printStackTrace (); }
catch(ParserConfigurationException e){
e.printStackTrace (); }
}
}
Book.xml

<?xml version="1.0" encoding="UTF-8"?>
<my:book xmlns:my="http://www.person.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.person.com Book.xsd">

<person>
<firstd><first>Johnthan</first></firstd>
<lastd><last>Schewatz</last></lastd>
<aged><age>38</age></aged>
</person>

<person>
<firstd><first>Bill</first></firstd>
<lastd><last>Gates</last></lastd>
<aged><age>46</age></aged>
</person>

<person>
<firstd><first>Steve</first></firstd>
<lastd><last>Jobs</last></lastd>
<aged><age>40</age></aged>
</person>

</my:book>


Book.xsd

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.person.com" xmlns="http://www.person.com" xmlns:f="http://www.first.com" xmlns:l="http://www.last.com" xmlns:a="http://www.age.com" elementFormDefault="unqualified">
<xsd:import namespace="http://www.first.com" schemaLocation="first.xsd"/>
<xsd:import namespace="http://www.last.com" schemaLocation="last.xsd"/>
<xsd:import namespace="http://www.age.com" schemaLocation="age.xsd"/>
<xsd:element name="book">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="person" type="persontype" maxOccurs="unbounded"/> </xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="persontype">
<xsd:sequence>
<xsd:element name="firstd" type="f:firstType"/>
<xsd:element name="lastd" type="l:lastType"/>
<xsd:element name="aged" type="a:ageType"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

first.xsd

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.first.com" xmlns="http://www.first.com" elementFormDefault="unqualified">
<xsd:complexType name="firstType">
<xsd:sequence>
<xsd:element name ="first" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

last.xsd

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.last.com" xmlns="http://www.last.com" elementFormDefault="unqualified">
<xsd:complexType name="lastType">
<xsd:sequence>
<xsd:element name ="last" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

age.xsd

<?xml version="1.0" encoding="UTF-16" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.age.com" xmlns="http://www.age.com" elementFormDefault="unqualified">
<xsd:complexType name="ageType">
<xsd:sequence>
<xsd:element name ="age" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

how to find out the version of X.509 certificate? (v1, v2 or v3)

At times, we require to find out the version of given X.509 certificate, whether it is v1, v2 or v3 type certificate. A key differentiator between version v1 and v3 is that v3 certificate have extensions, which v1 doesn't have. But, at times, it's difficult to know whether any extensions are there or not, or if information like Email Address are there, can you consider them as extension or not?

OpenSSL and Java SE 6 utility tool 'keytool' [1] from Sun Microsystem creates X509v3 certificates, whereas Java SE 5 or earlier keytool creates X509v1 certificate. Keytool can import and export v1, v2 and v3 certificates from keystores.

If you don't remember, or else you received certificates from some other source, then you can figure out using following,
Programming Approach: Use X509Certificate[2] interface to get access to extensions and version number.
try { // Load the keystore
File file = new File("mykeystore.jks");
FileInputStream is = new FileInputStream(file);
KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
// List the aliases
Enumeration enum = keystore.aliases();
for (; enum.hasMoreElements(); ) {
String alias = (String)enum.nextElement();
java.security.cert.Certificate cert = keystore.getCertificate(alias);
if (cert instanceof X509Certificate) {
X509Certificate x509cert = (X509Certificate)cert;
// Get Version no {X509CertInfo class gives version num starting from zero, hence if you get '2', it 's actually X.509 v3 certificate}
x509cert.getVersion();
// Get subject
Principal principal = x509cert.getSubjectDN();
String subjectDn = principal.getName();
// Get issuer
principal = x509cert.getIssuerDN();
String issuerDn = principal.getName();
}
}
} catch (java.security.cert.CertificateException e) {
} catch (NoSuchAlgorithmException e) {
} catch (FileNotFoundException e) { // Keystore does not exist
} catch (KeyStoreException e) {
} catch (IOException e) {
}

Use OpenSSL: Download and install OpenSSL [3] pre built binaries for Windows.

• Export the certificate to .CER format from the keytool -export command: keytool -export -alias myalias -file MYCERT.cer -keystore mykeystore -storepass mystorepassword
• Convert CER format to PEM format using openssl command: x509 -inform der -in MYCERT.cer -out MYCERT.pem
• Check the version using openssl command: x509 -in MYCERT.pem -inform PEM -text

You can see following information along with Validity, Subject, Subject Public Key Info and Certificate:
Certificate:
Data:
Version: 1 or 2 or 3
Serial Number: .....
Signature Algorithm: .....

Till now, you must have figured out what's the version of the X.509 certificate you are using. :)

[1]. http://java.sun.com/javase/6/docs/technotes/tools/solaris/keytool.html
[2]. http://java.sun.com/j2se/1.4.2/docs/api/java/security/cert/X509Certificate.html
[3]. http://www.openssl.org/related/binaries.html

Java EE 6, EJB 3.1, and JPA 2.0

JSR 316 for Java EE 6 is in place.
It has updates for: Servlet 3.0, EJB 3.1, JPA 2.0, JSF 2.0, JAX-WS...
and new JSRs Web Beans, JAX-RS (Restful Webservices), Work Manager and Timer
(Java Persistence API) JPA 2.0 forked from JRS 220 to a new instance JSR 317, new (Enterprise JavaBeans) EJB 3.1 is now filed as JSR 318.

Expected from the new version of JPA 2.0 is an API for "criteria" queries and the ability to have hierarchies of Embeddables.

Rod has written a good writeup about this.

Discover like never before

Two main components of service discovery are:

1. Discovery Architecture, and,
2. Service matching mechanism.

Service discovery in pervasive computing environments requires a decentralized design approach where a node should not depend on some other node(s) to advertise/register services. Each service should be autonomous and be able to advertise its presence. Moreover, the discovery should also adapt itself to reflect the changes in the vicinity.

A good idea is to multiplex service broadcasting and ior transmission from server to new clients.

service request broadcast has three disadvantages:

• Broadcast scales poorly with increasing network diameter and network size.
• It utilizes resources and computation power on all nodes of the network including nodes that do not even have the service or nodes that may not even fall in thr route of the desired services.
• It ulilizes significant network bandwidth, and creates a large load on the network.

Synchronous Communication and Concerns

Synchronous communication is a most straighforward way of communication. It is easiest to understand and incarnate. Most of the basic programs are based on it, from RPC to TP and Object Monitors.
But it has a few overheads which literally kills its advantages specially in certain distributed and enterprise communication models.

• It requires both parties to be online, it requires both parties to under go connection overhead.
• It requires both parties to maintain session of communication.
• To maintain session, both parties have to consume CPU resources for whole of 'live' time.
• Fault detection gets difficult as it is difficult to detect where the fault occured, is it at A, between A and B request communication, at B, or between B and A response communication.
• Fault Tolerance can be achieved by incarnating multiple service entities, but it requires to maintain their sessions also, it also requires have pools of them, and all this assuming it is stateless. If the service is statefull it gets more difficult.
• As seen from Fault Tolerance and session points, it is not a scalable approach.

Service Discovery and Broadcast

Two main components of service discovery are:Discovery Architecture and Service matching mechanism.

Service request broadcast has three disadvantages:

• Broadcast scales poorly with increasing network diameter and network size.
• It utilizes resources and computation power on all nodes of the network including nodes that do not even have the service or nodes that may not even fall in the route of the desired services.
• It ulilizes significant network bandwidth, and creates a large load on the network.

Clearly, service discovery in pervasive computing environments requires a decentralized design approach where a node should not depend on some other node(s) to advertise/register services. Each service should be autonomous and be able to advertise its presence. Moreover, the discovery should also adapt itself to reflect the changes in the vicinity.

Software Defined Radio's Chapter

Will soon put contents here... watch out for this space.

A Revisit to MRPs (Multicast Routing Protocols)

In general, there are three types of routing mechanism in MANET. Proactive (table driven) protocols use a traditional, distributed, shortest-path and maintain routes at all times. They impose a high overhead. Reactive (on-demand) protocols are initiated by the source. They have lower traffc compared with proactive protocols, but impose delay in route determination. Hybrid protocols are an adaptive way of combining proactive and reactive protocols.

DVMRP (Distance Vector Multicasting Routing Protocol) builds a source-based tree. AODV (Ad-hoc On-Demand Distance Vector Routing Protocol) builds a corebased tree. CAMP (Core Assisted Mesh Protocol) builds a mesh interconnection of hosts.

Message Broker - It's just to FIRE

Need for a Information flow graph that works over epidemic message brokership on MH entities, which would result in dynamic group creation, subscription of receipients along the path on graph.

I just found good number of reads, namely,

• In message broker space. Known to only two JMS and CNS, excited to discover CEA (Cambridge Event Architecture), HERMES, SIENA, JEDI, ELVIN


• In tuple spaces, LINDA, LIME (2 very well known), IBM Tspaces, Java Spaces, L2imbo


• In Pervasive spaces, CALAIS, Gaia, Nexus, Solar and One.World

I believe in Power of CORBA, do you? I will make you believe in this.

The Nature of Real Time CORBA - complete coverage

Real time CORBA developers require to give strict attention to the allocation and to the predictability of execution entities. Real Time CORBA has scrapped of a few things from normal CORBA in order to support real time systems.RT CORBA does not currently address dynamic scheduling. Real time CORBA does not define IDL for an activity. Instead of worrying about delimiting an activity, it deals with invocations of IDL defined operations.

A traditional CORBA program flow is like: An operation invocation consists of a Request and a Reply. It is initiated by some client computational context (e.g. a thread) and passes through a client-role ORB, a transport protocol (TCP in the case of GIOP), a server-role ORB (possibly involving queuing) to a server application. Thereafter the operation passes through the same entities in reverse order, back to the client.

RT CORBA uses four components namely,

• Scheduling support from OS
• Real Time ORB
• Transport medium
• Application

to respect three criteria of end to end predictability namely,

• Respective thread priorities between client and server for resolving resource contention
• Bounding the duration of thread priority inversions during end-to-end processings
• bouding the latencies of operation invocations

Thread Priorities: Real-Time CORBA defines a universal, platform independent priority scheme called Real-Time CORBA Priority. It is introduced to overcome the heterogeneity of different Operating System provided priority schemes, and allows Real-Time CORBA applications to make prioritized CORBA invocations in a consistent fashion between nodes with different priority schemes. Real-Time CORBA defines a NativePriority type to represent the priority scheme that is ‘native’ to a particular Operating System. Priority values specified in terms of the Real-Time CORBA Priority scheme must be mapped into the native priority scheme of a given scheduler before they can be applied to the underlying schedulable entities. Real-Time CORBA defines a Real-Time CORBA Current interface to provide access to the CORBA priority of a thread.
A Real-Time operating system (RTOS) sufficient to use for implementing a Real-Time ORB compliant with this specification, will have some discrete representation of a thread priority.

Priority Models: Real-time CORBA defines two models at which a server handles a clients request:

• A model in which server respects priorities of inivocations set by clients. Server ORB maps this Real-time CORBA priority to Native OS priority. Requests coming from a non Real-time ORB are handled according to server priorities
• Server handles the inovocations according to the Real-time priorities set by the server side

Thread Pools: Thread pools provides, preallocation of threads (helps in reducing priority inversion), partitioning of threads, bounding of thread usage, buffering of additional requests.

Other cool features:

• Real-time CORBA provides clients to obtain a non multiplexed connection, which will not be shared with other client-server communications.
• Allows applications to set a timeout on the invocation in order the bound the time the client is blocked and waiting for the response.
• Server side thread configuration.
• Configuration of priority models set by clients or server. A new Real-time CORBA POA policy would be created on aboves.

and finally, RTORB interface defines operations to create, destroy other constituents of Real-time ORB. There is a single instance of RTCORBA::RTORB per instance of CORBA::ORB. The object reference for the RTORB is obtained by calling ORB::resolve_initial_references with the ObjectId “RTORB”.

Data dissemination completed

It's been like the worst times, digesting them all and not finalizing them, I should make this moment, a moment to compose all in one.

There should be a ThreshValue on mobile nodes, configurable to the signal strength(interested in backchannel bandwidth), for controlling the push or pull behavior.

Push mode is bandwidth preserving in any environment, whether it's wired/wireless, I only difference is that it matters the most in wireless. But, at the end of day it depends on what's at application layer.

Let's try to classify this,

• 1. Parameterised service mode, (prime communication mode i.e. unicast pull)


• 2. Subscription mode, (service data broadcasts i.e. multicast push, if any by service to subscribers, broadcast items with highest count on Longest Wait First.)


• 3. Regular housekeeping communications, (handoff communication)


• 4. Parameterised housekeeping data transfer (code mobility, execution state transfer)


• 5. Parameterised service mode with multicast pull (aggregation of same request over a time span, hard to realize usability in practical cases, depends on usability, it's a intermediate stage between switching from 1 to 2)

I assume above all would be the communication modes, which all are required to be supported by the framework. Push characteristics of Message brokers can be used very effectively in 2 and 3. Ofcourse, In all cases, Message brokers would be used for data stroage for data availability.

An extremly good approach I feel is to broadcase hash-index of to-be multicast push items to subscribers to defer their unicast pull.

A important point to note here is, Heat adversely effects the reliability of the digital circuits and increases costs for cooling especially in servers. In order to access the desired data, a client has to be in active mode, waiting for the data to appear on the multicast. Enabling reliable communication on the message broker could be helpful in the sense of truly providing the intermittent devices asynchronous access to data. An broadcast indexing would make things even much better. The only low point is that in MANET, we don't have any super devices, all are peers, hence to save clients heat and effectively utilize Back Chaneel bandwidth, we require memory at the serving peer (so called server in Client Server environment).

About sensors workage

I came across a very interesting fact about working and robustness of currently deployed sensors, it is,

For a sensor network to maintain a lifetime of several years, for example, the radio’s duty cycle—the ratio of time the radio is on over time that the radio is actively sending or receiving a message—must typically be less than 1 percent.

Providing Push or Pull in MANET

Asymmetry happens in MANET not only due to communication behavior, but also due to

• Ratio of clients and servers


• Difference in downlink bandwidth and uplink ones


• Data Volume


• Hot data items

Push has a obvious advantage in MANET, as it

• takes same bandwidth for any subscribers


• Conserves energy by eliminating energy consuming uplink transmission, yields only if needy items are pushed


• Backchannel is missing or having poor bandwidth

Pull is also needed in MANET, as it

• is required for custom query or in on-demand mode


• much prefered mode when authorization is required.

A very interesting fact in regard to hot data items data dissemination is,
If p1,p2....,pn are the popularity ratios of data item, then their broadcast frequencies are f1,f2,...,fn, where fk = sqrt(pk)/sum of (sqrt(pks)) (By a paper of Imielinski et al)

Obviously, it is very favoring result for the push mode if we can sort hot data items at the cost of average access latencies of data items.

Flying car ready for takeoff?

This summer, graduate students at the Massachusetts Institute of Technology will try to get an idea aloft that has intrigued people for decades: the flying car.

Terrafugia, a start-up created by Lemelson-MIT Student Prize winner Carl Dietrich and colleagues at MIT's Department of Aeronautics and Astronautics, is aiming to show off what it calls the Transition "personal air vehicle," an SUV with retractable wings, to the EAA AirVenture Conference in Oshkosh, Wis., at the end of July.

The Transition is designed for 100- to 500-mile jumps. It will carry two people and luggage on a single tank of premium unleaded gas. It will also come with an electric calculator (to help fine-tune weight distribution), airbags, aerodynamic bumpers and of course a GPS (Global Positioning System) navigation unit.

Full report can be found at here

Message Oriented Middleware Communication Modes

The factors I depicted out for communication between peers are:
{Synchronous, Asynchronous, Transient, Persistent, Ack time)
in turn acknowledge enumeration can be made from ACK ENUM {Immediate, before response, response based, any}

We can make different combination of them,

• Persistent Asynchronous


• Persistent Synchronous


• Transient Asynchronous


• Transient Synchronous


• Recipient based Transient Synchronous


• Delivery based Transient Synchronous


• Response based Transient Synchronous

Persistent storage in pervasive environment can be defined as a storage on a mobile entity or set of mobile entities, such that demise of MH(s) should not result in loss of message.

Such that for any two entites, we need to define Sync/Async at A, Sync/Async at B, Persistence at A/Middleware/B, Message Acknowledgement ACK ENUM.

Phew! Mustang is out

Phew!
Mustang is out. To check out 10 hot things in mustang, go to Danny's weblog's entry
The 10 Things You Need to Know About Java SE 6 'Mustang'

Amazing/Amusing Stuff people do in Asynchrous Middlewares

Well, to avoid setup, search and registration confirmation latency while listening to a pub/sub in a new region. Virtual clients can queue up previous notifications and upon entities arrival they can dump the queued messages to newly arrived entity.

Good Points

• In case pub/sub JMS is not centralized then you can automatically discover other peers in the region. This would work in a centralized case also. But mobile framework I have supports peer MH (Mobile Host) discovery, hence first good point is not so good.
• A very good take can be in case queued notifications contains intermediate hop listings, then MH can update channel entires in routing tables with listed ones. It is a very good point I should say.

Bad Point

• Security is a concern, if entities are required to get only authenticated notifications only then things w'nt work it out as what newly arrived entity would be receiving are notification targeted to other entities.

Service Availability Estimation vs Service Discovery

I never got belief in this that computing time to be devoted in service
availability estimation rather than service discovery. A fact tells latency/overhead in 10 bytes of network communication is equal to 100000 CPU cycles. Huhh!!! Big figures, but look at the overhead involved in all this estimation if your prediction goes false, after all algorithms (Linear scaling or Bin) works on past records of service availability or service demise.

A good concept to take from service availability estimation is a fuzzy logic crieteria to compute device availability scale.

Mobile Service Buses

Mobile devices can work as service buses by consuming and transfering data collected from fixed/mobile sensors deployed in the region. Taking this as a PRD, the essential features required would be support for Asynchronous Communication, Support for Service Discovery, Need to differentiate between Service and Device discovery. The framework adds device discovery, but I am not very sure about whether the framework supports the Service Discovery. Let me think........

Well! after an intensive thought on the framework, service discovery is supported, but the service query APIs are not formulated, may be other service dimensions might also be in unstructured format, but yeah scalability is there and framework can have all the functionalities, I am very sure about this.

About asynchronous communication, a customize self organizing pub/sub service can help me to post up the functionality. But I need to investigate on that.

Facilitating Asynchronous Middleware

Facilitates:

• Servant Client Communication
• Route request and response message flows
• Mobility Layer handoff notifications (Device discovery)
• Surrogate Disconnection operation
• Service Discovery

Questions:

• Pub/Sub or Queue Hosting
• Discovery of Message Middleware

Answers:

• Vertical Message Queues
• Vertical Discovery Platform

Dimensions of Service Discovery

Need of Common Platform: With heterogeneous protocols supported by various entities involved in the virtual network, there would be diversity in service discovery protocols; hence a common platform or protocol establishment is a must requirement for enabling interoperability among service discovery protocols.

Dimensions:

• Service and Attribute Naming: Namespace based to avoid collisions and sustain uniqueness, human friendly service names, no usage of predefined templates for service names and attributes to support a common platform vision.


• Initial Communication Method: Unicast communication can only be used service discovery clients have specific prior configuration, hence such communication is infeasible in MANETs. A few Multicast messages to the directory, client can than proceed by explicit unicast messages. Link layer Broadcast can also work for a hop of distance.


• Discovery and Registration: Announcement based seems to be less suitable as client needs to listen and maintain a list of available services. Query based suits good to MANET and a client need not to process uninterested announcements.


• Service Discovery Infrastructure: Directory based models have a dedicated directory that maintains, processes, announces service information. This model is good when hundreds and thousands of services are incarnated in the network. Non-Directory based models have no dedicated components. When a query arrives, each service processes it; and replies if it matches with the desired one. A client can record service information for future usage.


• Service Information State: Soft State has an explicit service demise announcement; services too have explicit lease declaration in them, a graceful removal from the directory and announcement from the service itself. Hard State requires few service announcements and housekeeping. However, clients require to poll services to make sure that they are alive.


• Discovery Scopes: Proper discovery scopes minimize unnecessary computation on clients, services, and directories. Network topology based, User Role based, and Temporal Context based can be categorization of scopes.


• Service Selection: Although discovery scope can limit the number of service matches, there can a list of services available, and a selection could be required from them, Selection can be from user as manual, prompting user to choose or can be automatic, where the discovery protocol selects the service. This approach simplifies client programs and requires little user involvement. Good aspects that can be handled in automatic service selection are network hop distance to the service from requester client, load factor on services, service side robustness etc.

Pervasive Computing

I found a very good definition of pervasive computing:

It is characterized as a combination of distributed systems and mobile computing but also augmented by smart spaces, invisibility, localized scalability and uneven conditioning. A more detailed research space includes user intent, adaptation strategy, high-level energy management, client thickness, context awareness, balancing proactivity and transparency, privacy and trust.


When Edison finally found a filament that would burn, did he see the possibility of silent but pervasive electrical current flowing throughout our homes, cars and communities?

Known Issues

• Mobile phones do not yet support an IP stack over Bluetooth. Devices which only support Infrared or ZigBee would be disconnected from the virtual network created by framework.

Live on Wireless

Amazing new world utilities coming up now a days, below are a few to seek out,

Handheld equipment hoping on reconfigurable frequencies defined by middleware stacks (Extremely useful in military applications)

Context aware applications ranging from vehicular computing to Sensor based Ad Hoc computational systems, that is your car system can automatically adapt its configurations (may be speed in automatic drive, transmission ratios of gear box, audio tracks of your sound system) according to the profile of the user driving the car

Server side components for handheld devices

Virtual Home Imaginations (HP is going great work in it)

Frameworks to support heterogeneous MAC layer environment, so that your handheld can now navigate seamlessly on Bluetooth, CDMA, GSM, 802.11 (a-g), even to 3G networks

Dynamic service composition and delegation, such that your handheld can request a service and according to the request attributes, hosted services can jointly combine and process the request.

and Disconnection operation to name a few (a scenario can be like, your doctor can asynchronously prescribe you diet of specific calories even when you are not in doctor's clinic and you can view that on your mobile or laptop while taking a morning walk in some lush green vally...

Asynchronous Communication

There is a essential need for component(s) to support asynchonous behavior. Main points are:

Exchange of Request data and Response data between server and client. Particularly at the time of demise or disconnection of the receiving entity (in case of response from MH), assuming that sending operation is successful. Also in request scenarios where FH has pushed the request, but the request is travelling along the network but not reached to the server.

Exchange of control information between Routing layer. Exchange of Mobility layer connection information, handoff information.

Message broker can hence act as delegate, as indirectly it would be supporting disconnected operation.

TODOs:

Component identification and deployment diagram

Issues of hosting JMS and CNS on low footprint devices.

Many more...

What lies Next

I listed following points on 08 April, 2005,

Impromptu Service Discovery - UPnP, JINI, SLP protocols

Minimal CORBA - low footprint

Asynchronous Behaviour - asynchronous messaging of request-responses, cache, use of CNS

Network Adaptation - access to MAC layer, adaptation according to MAC layer

Disconnection Operation - object by value, externalization and life cycle services, Use of mac layer for switching modes

Optimizing IIOP layer communication - analysis of architecture

Integration with Non- CORBA clients- SOAP, web service clients and others

Security Aspects- Authentication and Authorization services, security services

Early thoughts on Mobile ad-hoc networks - using Peer-to-Peer Computing

In last 8 months I delved inside very few of above, but I am recharged now, I would move to following points (In priority):

Asynchronous Behaviour - asynchronous messaging of request-responses, cache, use of CNS

Minimal CORBA - low footprint

Disconnection Operation - object by value, externalization and life cycle services, Use of mac layer for switching modes

Network Adaptation - access to MAC layer, adaptation according to MAC layer

Integration with Non- CORBA clients- SOAP, web service clients and others

Optimizing IIOP layer communication - analysis of architecture

Security Aspects- Authentication and Authorization services, security services

Epidemicity

Ad hoc networking modeling with Omnet++

Implementation of client side request interceptor

Relook at Layers

Message Middlewares for Asynchrony

Ad hoc On-Demand Distributed Minimal Hop based Cycle eliminated Routing Algorithm

1 u = v

1.1 Nbu[v] = local

2 if u!=v then, Nbu[v] w, where w is the first neighbour of u on a shortest path from u to v
(Multithreaded operation at u)

2.1 Sends Rreq to Neigh[u]

(operation at w)
2.1.1 For each Neigh(u) having d(v) in cache

2.1.1.1 Reply to Rreq to u by exponential time proportional to hops to v.

(Route Maintainance Operation)
2.1.1.2 Make a Async message (mydist, v, d) to all its neighbours

(operations at Neigh(w) say z)
2.1.1.2.1 Receive message (mydist,v,d)
2.1.1.2.2 Decide on d(z,v)<= d(w,z)(1)+d(w,v)
2.1.1.2.3 Reply to w if false (notifying that path from w is minimal)
2.1.1.2.4 Update Cache, Nbu[v] vector = w
2.1.1.2.5 Notify Neigh(z) about change

2.1.1.3 Make a reverse route entry by Lsd

2.1.2 If d(v) = ndef (Recursive Route Discovery operation)
2.1.2.1 Sends Rreq to Neigh(w)
2.1.2.2 Append route list Lsd with w

2.2 Receive and process Rres

2.2.1 For Rreq TTL accept Rres
2.2.2 Process minimal hop and 2.2.3 Extract Lsd and make route entry for Destination and Intemediate nodes too.

3 If no route to v

3.1 Neigh(v) = udef
3.2 Propagate Rerr to intermediate nodes so that stale entries (containing route for v from u) in other Uks can be removed.


Satifiability conditions for Nbu[v]
a if u=v, then, Nbu[v] = local
b1 if u!=v then, Nbu[v] w, where w is the first neighbour of u on a shortest path from u to v
b2 if u!=v then, and for all w Dw[v] >= N-1, then Du[v] = N {u and v are in different connected components}
c if no path from u to v exists then Nbu[v] = udef

Routing table characteristics in Mobile Adhoc NETs

Robustness - In case of topological changes.
Adaptiveness - In case of heavy load at particular links (paths) hence some alternative paths need to be selected.

Routing Characteristics can be categorized as:

Minimal hops

,

Shortest path

, and,

Minimal delay

Good observation: A minimal (optimal) path need not to be unique. That is, there may exist other paths of the same cost. Then, load factor on the shortlisted candidates can be a good decisive factor.

802.11 Notes continues...

Bit Error Rates in Wireless medium are the main drawback of them, comparatively BERs in Wireless medium are 10 times more than Wired LAN cables. The main reason for BERs are Atmospheric Noise, Physical Obstructions along the path, Multipath Propagation and interference.
Most of the WLANS operate on Spread Spectrum Modulation. which operates over a wide amount of bandwidth. Interference is also caused by multipath fading of the WLAN signals, which results in random phase and amplitude fluctuations in the received signal.

Inward interference comes from devices transmitting in the frequency spectrum used by the WLAN. A number of techniques the operate either on the physical or MAC layer like, Alternative modulation techniques, antenna diversity and feedback equalization in the physical layer, Automatic Repeat Requests (ARQ), Forward Error Control (FEC) in the MAC layer are used to mitigate this inteference.

Outward interference occurs when the WLAN signals disrupts the operation of adjacent WLANs or radio devices.

Further problems are Hidden and Exposed terminal cases.

Physical layers:

IR: operates near to visible rays wavelength 850nm, produced by semiconductor laser diodes or LEDs, since their electrical to optical conversion behaviour is linear.
Can be produced using one of three ways: Diffused transmission in omni direction, reflection by ceiling or focused transmission. IRs are demodulated at the receivers using their amplitude, not their frequency or phase, reduces the receivers complexity. IR rediatons are immune to electromagnetic noise. IR systems share a part of spectrum that is also used by the Sun, hence can work practically in indoor application, same the case with Florescent lights. The IEEE 802.11 physical layer specfication uses Pulse Position Modulation (PPM) to transmit data using IR radiation. PPM varies the position of a pulse in order to transmit different binary symbols. IR transmission works at 1 or 2 Mbps.

RF: RF is robust to florescent lights and outdoor operations, can penetrate non-metalic objects. RF equipment is subject to increased cochannel interferece, atmospheric and man-made noise, high-current circuits.
RF Bands: 902 MHz, 2.4 Ghz and 5.8 Ghz
Adv Factor: The higher the RF band, lesser would be the interfernce.
Disadv Factor: The higer the band, lesser would be the transmission range.
Spread Spectrum: RF uses spread spectrum technology. The idea is to spread the transmitted information over a wider bandwidth in order to make interception and jamming more difficult. In a spread spectrum system, the input data is fed into a channel encoder, which uses a carrier to produce a narrowband analog signal centered around a certain frequency. This signal is then spread in frequency by a modulator, which uses a sequence of pseudorandom numbers. At the receiving end, the same sequence is used to demodulate the spread signal and recover the original narrowband analog signal. The recoverd original narrowband analog signal is fed into a channel decoder to recover the initial digital data. The hopping sequence is defined by the 'seed' of the random number generator.
Spread spectrum has been proven very effective in combating fading. Since a spread spectrum is very wide in frequency, fading only affects a small part of it.

FHSS: Hops over frequency to frequency. Time spend on one frequency is called a chip. The receiver executes the same hopping sequence while remaining in synchronization with the transmitter and thus receives the transmitted data.

DSSS: Each bit in the original spectrum is represented by a number of bits in the spread signal. This can be done by binary multiplication (XOR) of the data bits with a higher rate pseudorandom bit sequence., known as the chipping code. The resulting stream has a rate equal to that of the chipping code and is fed into a modulator, which converts it to analog form in order to be transmitted.

Bit Rates: IEEE 802.11 covers FHSS, DSSS and Infrared Technologies. IEEE 802.11b works at 5.5-11 Mbps and uses DSSS for spreading the spectrum. IEEE 802.11a (HiperLAN2) operates at 5Ghz, and acheives data rates around 54 Mbps. It uses OFDM as opposed to spread spectrum used in Bluetooth, 802.11 and 802.11b. Bluetooth hops around 1600 hops per second which is extremely high as compared to IEEE 802.11 (2.5 hops per second). Thus, due to overhead of switching between the frequencies could cause some delays, and affect the throughtput in that way, that's why actual output data rate of bluetooth is around 30 to 400 kbps, whereas that of 802.11 is 1-2 Mbps. Obviously, 802.11b has a higher data rate than 802.11, 5.5-11 Mbps.

Interoperability of protocols

Overlapped and heterogeneous protocol support for servant clients. Support of Discovery at different protocols is a great feature. Moreover, Services from servants can interoperate with services at different protocols. Enterprise Service Bus can support the features and interoperbility of services.

About Service Discovery Architecture

Service Location Protocol: Directory Agents are the renaming of MGs or various central authorities. Service and User Agents resides on the mobile devices and work the same as a subset of the CORBA framework components.

JINI: Has a Jini Lookup Service (JLS), exactly as MG.

Universal Plug and Play: UPnP uses SSDP over HTTP in two fashions, UDP(HTTPU) and UDP(HTTPMU). A service joining can unicase or multicase to the default selected set of clients or peers about it's arrival in the network and start of service. A client can directly contact a server based on URL or can multicase a request. UPnP seems to be a resonably good one since its architecture says 'NO' to centralized directory server.

SALUTATION: The salutation architecture defines another centralized entity as Salutation Manager (SLM), exctly as SLP's Directory Agent, or JINI's JLS or Nomadic's MG.

CONCLUSIVE POINTS
About UpnP
Hence, I am going to write or delve deeper into Universal Plug and Play only in the further blog contents. UPnP has five steps in all:

Discovery:

Based on SSDP over HTTP. When a device comes it multicast to the control point about it's service description. When a control point comes, it searches for devices of interest on the network.

Description:

After discovering the device, the control center retrieves the device (I assume service too) description from the URL provided by the device.

Control:

Control point sends control message to the control URL for the service.

Eventing:

In case service changes any of the service variables or other information about itself, it informs the control center with a event message about the change.

Presentation:

Some devices provides a URL like MBeans to allow a user to view device status or control the device.
About SLP

Advantage factor of SLP is that it supports service browsing and string based query.

About Nomadic

Cooperation among MG's in nomadic environment is also a good thing to do.

Few Points
Advantage of Nomadic over MANET are:

Scalability

Response Time

Load Balancing

Dimensions of Discovery

I can classify various discoveries in MANET and Pervasive computing as:
a.) Route Discovery
b.) Device Discovery
c.) Service Discovery

I can also classify demises in:
a.) Device Demise
b.) Service Demise
c.) Route Demise

I can classify the maintainance as:
a.) Route Maintainance

As far as Demise and Discovery dimensions are concerned:
Device property is a superset of the Service property. That means that happening of the Device entity would result in the same happening of the Service entity.

Nightly

DNS - IP address - Produces IOR
Since there is no MG, hence at time of birth there is no need to produce IOR.
MH produces original IOR and ukey or Hash and distributes to all neighbour MHs to make an entry in their tables.
On movement Birth MH might not be connected to the old set of MH and might be connected to the new set of MH.
Birth MH notifies new set of MH not the old set of MH.
How old set of MH would be notified about the IOR getting dirty?
On movement of MH, devices which are immediate neighbour would get notified about device demise.
Request can be received from MH or FC.
In CORBA, a request can only be launched if a client has IOR.
1. An IOR can be distributed to the connected consumes(FC or MH).
2. A request of search can be issued by consumer (FH or MH) to connected MH by giving some search attributes, so that the receiving MH can do:
2a. Forwards the request attributes to it's connected MH if can't be answered.
2b. Replies back to the client with the modified or swapped IOR.

In approach 1, as IOR gets dirty it becomes difficult to trace. There would a heavy overhead of the distribution of the new IOR, I think this would need to be distributed to almost all.
In appraoch 2, a search request would be forwarded and it need to return the latest IOR or IOR information.
In appraoch 2, a category of identifying parameter needs to be passed by the servant to the birth MH and then by birth MH to connected MH, so that searching of the servant based on attributes can be done.

On movement the search attribute related entry in registers of neighbour MH is modified, so that the latest entry remains.

AODV (Ad Hoc On Demand Distance Vector)

Introduction
combination of DSR and DSDV.
Route discovery and maintainatance from DSR.
Hop-by-hop, sequence number and periodic updates from DSDV.
Rreq packets contains last known sequence number for destination.
When a node recives a Rreq for a destination it has a route to, it generates a Rrep with the updated sequence number and number of hops.
Each node that forwards the reply back to the originator creates a forward path to the destination.

DSR (Dynamic Source Routing)

Introduction
1. Source routing (full routing information)
2. On demand routing updates
3. Route Discovery and Maintainance
4. Bidirectional routing information updates by reversing the route request path.
5. Source initiates the Rreq (having Vs,Vd,Lsd).
6. Destination receives Rreq (may be more than one over the period of time), then sends a Rrep (a reverse mesaage) from the path which has shortest Lsd listing.
7. Intermediate nodes (Vi-Vj) also communicates bidirectionally to update their information. If fails then, Vi informs the Vj about Rerr and Vs initiates a new Rreq with a different route.

About DSDV (Destination Sequences Distance Vector)

Introduction:
Each node maintains a set of distance or cost vectors for each possible destination.
Each node periodically broadcasts its routing table to all neighbours.
The routing is hop by hop.
Predicated table structure tuple can be like this:

{Destination Mobile Node Identifier,Sequence Number, Next Neighbour hop information in direction of deestination}

Routes have sequence number.
Routes with higher sequence number are more favorable.

Questions:
1. Periodic updates should be send and received from whom ?
Each node periodically broadcasts its routing table to all neighbours.

2. Route decisiveness based on what matric ? weight or latest or other factor ?Latest is a must as the use of sequence number shows.

Advantage Factors:
1. Guarantees loop-free routes.
2. Simple logic. (Should not be considered as adv. point)

Disadvantage Factors:
1. Hop by hop routing instead of Source routing.
2. Periodical updates.
3. Heavy overhead of exchange of routing information between neighbours.

Merger Notes Revised

Efficiently route or request data among entites.
Topology of network is dynamic due to intermittent connections.
There always requires an flooding sort of algos for going to p2p side, but raises the scalability problems. Need to take things from application layer to network layer as the P2P and MANET ranges the same. Good sign is CORBA framework proposed in my previous paper also ranges the same hence all issues can be taken into consideration and solutions can be mergerd with the disconnection, swizzling, mobility (I and II) layers. Mobility layer is going to work extensively in the revised version.

Peers should communicate to each other periodically.
These protocols should be triggered more frequently for MANET.
I can convert MHR into a neighbour tablefor nearest keys for DHT, that would imporve robustness and they need to be updates periodically.

Discovery mechanism

Rship Approach: Forward discovery queries using similarity, history and random Rships.
Updating Rships can be the activity performed while migration of servants.
Acquiring Rships can be performed as conduction process.
Discovery result backtracking would make system to learn much quicker.
Tradeoffs are overheads in all above operations.

Does above works better than Distributed Hash Table? Consider two cases for comparision: a) when the queries are similar and b) when queries are random.

Flooding: Obviously, it is going to take too much bandwidth, so it arises scalability issues.

Distributed Hash Table Algorithms: In this systems, every entity(file) and peer are assigned a unique key by a hash function. The keys along with the network addresses of peer storing the files are evenly distributed among all participating peers. Each peer maintains a routing table and queries are forwarded to only those peers which are listed in the routing table.

Need to exploit synergy

Need for a decentralized and self organized discovery algorithm that can leverge with the servants and device migration.
A tranformation algorithm which would make Nomadic to MANET, an algorithm that should exploit a synergy between P2P overlay networks and Mobile Ad-hoc Networks using an approach of Distributed Hash Table.

Migration from Nomadic to MANET

Does IOR distribution mechanism relates to p-p discovery algos, Flooding ,CAN, CHORD or Pastry? Nope, cuz as they are content algos, thats why they can work with Pure P-P and P-P with discovery.

Entities MG, MH, and FC are workable in P-P environment? To start with, MH and FC are obviously different entities. But yeah, MHs and FCs can be combined to work in P-P envirnment.

Do I require Discovery algorithms? Yes.

Which discovery algorithm suits the framework well ?

What after discovery? As they discover, then framework can go for Content based algorithms (in case services are different), and then go for IOR distribution. In case if services are same then framework can directly distribute the IOR.

In process of servant migration, as the client IOR gets dirty, then in case of P-P or MANET how framework would manage the old IOR context?

There requires a need for Async communication or real time message propagation

P2P algorithms

Ubicomputing Killer Apps

Traffic Management Domain:

• An accident warning service provided by a crashed car to approaching vehicles.
• A warning service provided by an ambulance rushing to an accident side to inform nearby vehicles to yield the right of way.

Business Domain:

• A service provided by the lead of meeting to get poll information from attendes, registering the persons attending the meeting.

Service Domain:

• Personal information service hosted on PDAs.

Common Characteristics of Discovery Mechanisms

Common Characteristics:

• Discovery Service (SLP is good)
• Service Subtyping
• Service Appearance and Disappearance: Highly dynamic updates in both service arrival and demise (except crash of service)
• Service Browsing
• Catalogs of Available services: UPnP is inherently P2P, hence doesn't require catalogs to be published, Jini publishes catalogs for clients, whereas SLP has both options.
• Eventing
• Garbage Collection: Leases are a popular garbage collection mechanism.

Overviews:

SLP:

• User Agents(UA) search for needed services on behalf of clients.
• Language Neutral.
• (OpenSLP)

UPnP:

• Device and service descriptions are coded in XML.
• UPnP does not support service directories - communication between devices and clients is always direct.
• UPnP is aimed at smaller environments.
• (UPnP SDK)

Bluetooth:

• Blutooth devices maintains sets of service records, each of which describes an available service.
• Is lightweight , because it is meant for Personal Area Networks

Peer to Peer and MANET

mobile p2p systems are : self organising, fully decentralized, highly dynamic

you have to tackle two issues : unstable connectivity, unpredictable IP addresses

you have to predict the presence of peer, share configuration with peers and notice when they become unavailable

peer discovery must be timely and efficient

security aspects: must have encryption and robust authentication

Points

Should approach for Mobile Ad-hoc Networks
Use of Peer-to-Peer Computing
Utilize the Service Discovery mechs like Own, UPnP, SLP or JXTA
Intermediate use of own's Logical mobility mech and location tracking

Impromptu Service Discovery - JXTA, UPnP, SLP, JINI protocols

Mobile server objects are quite similar to the work done in paper "proximity based service discovery in manet", feels great to work parallel work to Vinny.
They have used event based middleware, to discover the services as of event producers.

9 Points Agenda - Works to be done

• Impromptu Service Discovery - UPnP, JINI, SLP protocols
• Minimal CORBA - low footprint
• Asynchronous Behaviour - asynchronous messaging of request-responses, cache, use of CNS
• Network Adaptation - access to MAC layer, adaptation according to MAC layer
• Disconnection Operation - object by value, externalization and life cycle services, Use of mac layer for switching modes
• Optimizing IIOP layer communication - analysis of architecture
• Integration with Non- CORBA clients- SOAP, web service clients and others
• Security Aspects- Authentication and Authorization services, security services
• Early thoughts on Mobile ad-hoc networks - using Peer-to-Peer Computing

Hello World !

The most necessary and primary step that every programmer climbs many times but with different boots.