Weblogic LDAPAuthenticator configuration; the GUID Attribute

LDAP servers can be configured to use as authenticator in Weblogic Server. In order to efficiently use an LDAP server, it must be possible to uniquely identify LDAP objects. GUID attributes can be considered a unique identifier for an LDAP object. There are several specific and some more generic LDAP authentication providers available for Weblogic Server. The specific authentication providers have default GUID (global universal identifier) attributes (see here at 'Use of GUID and LDAP DN Data in WebLogic Principals'). When using the generic Weblogic Server LDAPAuthenticator, there is no default GUID attribute. In order for LDAP caching to work and to allow browsing of group memberships for users, the GUID attribute needs to be defined. The entryUUID is a good candidate for this since every LDAP server should support it. See RFC 4530. Also see here.

Some thoughts on Continuous Delivery

Continuous Delivery is something a lot of companies strife for. It is a software development practice which allows quick (continuous) delivery of software. Quick delivery means the software can quickly provide business value. Why is it difficult to achieve and what are the challenges which need to be faced? Inspired by a Continuous Delivery conference in the Netherlands and personal experiences, some personal thoughts on the subject. The bottom line is that it requires a cultural change in a company and it is a joint effort of several departments/disciplines to make it work. The below image is taken from here. The Continuous Delivery maturity model is an interesting read to understand what Continuous Delivery is and provides a way to measure where you are as a company.

Using Maven to assemble and release artifacts to Nexus

An important part of a release process is storing artifacts in an artifact repository. Many customers use custom implementations of artifact repositories (such as file shares in combination with custom scripts) but there are also products which offer many functions of such a repository (and probably many more) out of the box so that custom implementations are not necessary anymore. Nexus is an example of a popular artifact repository. An added benefit of using a popular product to provide repository functionality is that a lot of development tools can easily be integrated with it. Maven can easily be used to compile and assemble code and deploy it to a Nexus repository.

In this blog I will provide an example of how a shell script (as an example artifact) can be packaged and deployed to Nexus by using Maven. I will use the maven-assembly-plugin to package the script, the nexus-staging-maven-plugin to deploy to Nexus and the maven-release-plugin for the version control part of the release process.

 

Oracle Service Bus: Obtaining a list of exposed SOAP HTTP endpoints

The Oracle Service Bus is often used for service virtualization. Endpoints are exposed on the Service Bus which proxy other services. Using such an abstraction layer can provide benefits such as (among many other things) monitoring/logging, dealing with different versions of services, throttling/error handling and result caching.

In this blog I will provide a small (Java) script, which works for SOA Suite 11g and 12c, which determines exposed endpoints on the Service Bus.

SOA Suite 12c: Getting started with the Spring Component

The Oracle SOA Suite Spring component has been present since SOA Suite 11.1.1.3 (11gR1 PS2). This component allows easy integration of Java code with other SOA Suite components such as (among others) BPEL, BPM and Business Rules. In SOA Suite 12c (12.1.3.0) this component is still present. In This blog post I will provide a short example on how it can be used and how the first problem I encountered with this component can be avoided.

ADF and service dependencies

In order to keep the business-IT gap manageable, it is important for analysts, designers and architects to know what their implemented application landscape actually looks like. An important part of this is insight in dependencies between different components. In my previous blog post I’ve described how service dependencies can be determined. In this blog post I will provide a script for analyzing which services are called by ADF pages. Keep in mind both analyses are executed on source code. This can differ from the runtime environment.

The Oracle ADF framework consists (among other things) of several XML files which refer to each other. This comes in handy when you want to analyse ADF code since XML is easily parsed and queried. In order to determine service calls I have made the assumption that webservice calls are executed using the excellent the ADF EMG XML DataControl by Wilfred van der Deijl and Richard Olrichs as announced on http://www.olrichs.nl/2014/05/announcement-adf-emg-xml-datacontrol.html and presented at OOW 2014.

Oracle SOA Suite 11g and 12c: Determining composite dependencies to the level of individual operations

In large companies, often there are many services and dependencies between services. It is important to track service dependencies in order to for example estimate the impact of changes. Design documents or architecture views can be used for this but as everybody knows, there is often a gap between theory and practice (design and implementation).

In this blog post I provide code to determine dependencies between composites to the level of operation calls. In order to achieve this, I'll parse the composite.xml files, JCA files (used by adapters) and also the BPEL and BPMN files in order to determine the operations. The script can be used for SOA Suite 11g and 12c composites.

The above picture shows different parts of which a composite is composed and how they are linked. The script first determines references. The references specify which external services are called. Then by using wires, the relevant components are determined. Based on the component type, specific logic is used to extract the operation. Not shown in this picture is how database dependencies can also be determined by the script by parsing the JCA files specified in the reference. If you're in a hurry, you can go to the 'Executing the script' part directly and skip the explanation.