Friday, January 30, 2015

Mastering Apache Maven 3

Maven is the number one build tool used by developers and it has been there for more than a decade. Maven stands out among other build tools due to its extremely extensible architecture, which is built on top of the concept, convention over configuration. That in fact has made Maven the de-facto tool for managing and building Java projects. It’s being widely used by many open source Java projects under Apache Software Foundation, Sourceforge, Google Code, and many more. Mastering Apache Maven 3 provides a step-by-step guide showing the readers how to use Apache Maven in an optimal way to address enterprise build requirements.


 Following the book readers will be able to gain a thorough understanding on following key areas.
  • Apply Maven best practices in designing a build system to improve developer productivity.
  • Customize the build process to suit it exactly to your enterprise needs by developing custom Maven plugins, lifecycles and archetypes. 
  • Troubleshoot build issues with greater confidence. Implement and deploy a Maven repository manager to manage the build process in a better and smooth way. 
  • Design the build in a way, avoiding any maintenance nightmares, with proper dependency management. 
  • Optimize Maven configuration settings. 
  • Build your own distribution archive using Maven assemblies. Build custom Maven lifecycles and lifecycle extensions.
Chapter 1, Apache Maven Quick Start, focuses on giving a quick start on Apache Maven. If you are an advanced Maven user, you can simply jump into the next chapter. Even for an advanced user it is highly recommended that you at least brush through this chapter, as it will be helpful to make sure we are on the same page as we proceed.

Chapter 2, Demystifying Project Object Model (POM), focuses on core concepts and best practices related to POM, in building a large-scale multi-module Maven project.

Chapter 3, Maven Configurations, discusses how to customize Maven configuration at three different levels – the global level, the user level, and the project level for the optimal use.

Chapter 4, Build Lifecycles, discusses Maven build lifecycle in detail. A Maven build lifecycle consists of a set of well-defined phases. Each phase groups a set of goals defined by Maven plugins – and the lifecycle defines the order of execution.

Chapter 5, Maven Plugins, explains the usage of key Maven plugins and how to build custom plugins. All the useful functionalities in the build process are developed as Maven plugins. One could also easily call Maven, a plugin execution framework.

Chapter 6, Maven Assemblies, explains how to build custom assemblies with Maven assembly plugin. The Maven assembly plugin produces a custom archive, which adheres to a user-defined layout. This custom archive is also known as the Maven assembly. In other words, it’s a distribution unit, which is built according to a custom layout.

Chapter 7, Maven Archetypes, explains how to use existing archetypes and to build custom Maven archetypes. Maven archetypes provide a way of reducing repetitive work in building Maven projects. There are thousands of archetypes out there available publicly to assist you building different types of projects.

Chapter 8, Maven Repository Management, discusses the pros and cons in using a Maven repository manager. This chapter further explains how to use Nexus as a repository manager and configure it as a hosted, proxied and group repository.

Chapter 9, Best Practices, looks at and highlights some of the best practices to be followed in a large-scale development project with Maven. It is always recommended to follow best practices since it will drastically improve developer productivity and reduce any maintenance nightmare.

Thursday, January 15, 2015

WSO2 Identity Server 5.0.0 - Service Pack 1 is now is publicly available

You can now download the WSO2 Identity Server 5.0.0 - Service Pack 1 from http://wso2.com/products/identity-server/.

This Service Pack(SP) contains all the fixes issued for WSO2 Identity Server 5.0.0 up to now.

Installing the service pack into a fresh WSO2 Identity Server 5.0.0 release, prior to the first start up. 

1. Download WSO2 Identity Server 5.0.0 (wso2is-5.0.0.zip) and extract it to a desired location.

2. Download WSO2-IS-5.0.0-SP01.zip, extract it and copy the WSO2-IS-5.0.0-SP01 directory to the same location, where you have wso2is-5.0.0.

3. The directory structure, from the parent directory will look like following.

    /----
       |--wso2is-5.0.0
       |--WSO2-IS-5.0.0-SP01

4. In the command line, from the 'WSO2-IS-5.0.0-SP01' directory run the following command.

   On Microsoft Windows: \> install_sp.bat
   On Linux/Unix: $ sh install_sp.sh

5. Start the Identity Server.

   Linux/Unix : $ sh wso2server.sh -Dsetup
   Windows : \> wso2server.bat -Dsetup

 6. Open the file, wso2is-5.0.0/repository/logs/patches.log and look for the following line. If you find it, that means the service pack has been applied successfully.

INFO {org.wso2.carbon.server.util.PatchUtils} - Applying - patch1016 Installing the service pack into a WSO2 Identity Server 5.0.0 release, in production already.

If you have an Identity Server instance running already in your production environment - and want to update it with the service pack, please refer the README file which comes with the service pack itself.

Thursday, December 4, 2014

LDAP vs Database

1. LDAP is mostly picked over Database if the read/write ratio is more than 10,000/1 (this number is bit arguable) - since its more optimized for read operations. So in general LDAP is more preferred for static data.

2. LDAP has scalability concerns - even Microsoft recommends MS SQL server over Active Directory - if the user base is more than 1.5 million. In most of the large scale deployments I am aware of Database is preferred over LDAP. There are some cases where people use MySQL to handle 60 million users. Some US state governments use MS SQL server to manage citizens. So, the rule-of-thumb is if the user base is less than 1 million then LDAP should fine. But, if it exceeds that then better to go ahead with a proven Database. Also  note that more than 90% of Fortune 500 companies use Microsoft Active Directory.

3. LDAP implementations provide more in-built functionalities like, password update/rotation policies, fine-grained access control via ACLs, account locking, groups and etc. If you are using a Database as the user store, then either you need to implement all those by yourself or use a third-party identity management system on top of the Database.

4. LDAP has inbuilt support to manage hierarchical relationships between user entities. If this is a requirement, and go for a Database - has to be implemented from the scratch.

5. Transactional data related to the user should not be stored in the LDAP. Those have to be maintained in the Database and linked to the LDAP user via entryUUID.

6. LDAP has inbuilt support for multi-valued attributes. Say someone can have multiple email addresses - phone numbers - LDAP by design supports keeping multiple values against the same attribute. If this is a requirement and go for a Database - has to be implemented from scratch.

7. LDAP has an inbuilt security model over the data it stores. You can define ACLs over attributes and sub-trees. We don't find this in a Database and has to be implemented from scratch.

 8. Both in LDAP and JDBC, the schema can be extended.

9. Integration with third-party applications is much flexible with LDAP - since its a standard

Wednesday, December 3, 2014

OpenID to OpenID Connect