In this blog entry I explore the use of an LDAP directory and infrastructure to establish a single directory for authentication and user management in an Oracle WebLogic environment.
I have been working and consulting around [Oracle] WebLogic for quite some time. When it comes to user management, the use of the embedded LDAP server (shipped with WebLogic Server) is the most common configuration I have come across. This means that a user directory exists for every domain.
Let’s assume a customer site (like the one I am on currently) require 5 environments to support their software development lifecycle (Development, Test, QA, Staging and Production). Every environment consists of two WebLogic domains; an Oracle Service Bus domain and an Oracle SOA Suite domain. That is a sum total of 10 user directories. Managing user data across 10 directories, even when using bulk import and export facilities, can be an error prone and time consuming administrative task. Just think of the complexity when members from various development (or support) teams require varying levels of access to two or more of the environments.
Wouldn’t it be easier if we could centralise the user directory and establish a simple delegation model to ensure the right people, get the right level of access without having to create users in 10 WebLogic domains separately? The rest of this post will focus on what is required, from a functional point of view, to establish a centralised LDAP infrastructure.
We have to address two key areas to establish the LDAP infrastructure, which we will cover in the sections that follow:
- Design a server topology to allow all WebLogic Server domains to connect to a central LDAP directory.
- Establish a delegation model that can be administered centrally.
Back in April 2011 I didn’t intend writing a three part series of blog entries about technical web service design. But here we are in the third installment. In the first post I used a very simple synchronous interface to demonstrate a design process and tool chain; in the second post* I covered the installation and configuration of the tool chain.
Now we will use the process and tools to design interfaces that support various Message Exchange Patterns (MEPs). We will focus on the mapping between the MEP requirement, the JAX-WS based Java interface and the WSDL artifact. Four commonly used MEP’s will be covered:
NOTE: You will need a basic understanding of the design process and guidelines described in the first post to follow the discussion in this post.
In my previous post I presented a simple technique to create technical web service designs. I touched on the tools and the process and provided some code examples with guidelines. In this entry I will run through a procedure to establish a simple environment where you will be able to create your own designs. At the end you should be able to run the ant command to produce all of the design artifacts for a basic web service design project.
In this blog entry I present a simple technique to create technical web service designs using a Java based tool chain.
At first I wanted to title this entry: A meta-guide to technical web service design for geeks or how not to shoot yourself in the foot. Looking back at past experiences, that is exactly what happens; for some inexplicable reason service interface design is neglected and we end up with a great number of web services that accept input similar to the following:
Passing XML (as a string) within an XML wrapper is not very self describing. The XSD used to describe the XML instance document above will not contain the required
hello structure (line 3), it will only describe the
input element (line 2) as being of type
xsd:string. This leaves the poor consumer of the web service completely in the dark with no idea what the actual required input to the service must be (by just looking at the WSDL document). Bam!, you just shot yourself in the foot, fielding 10 calls a day from people asking what the input to the service should be. And how about that XML namespace (line 1); I won’t even bother talking about the (mis)use of XML namespaces, not to mention the problems caused by not qualifying XML documents properly.
Web Services technologies are possibly the most pervasive in realising or exposing the functional aspects of SOA services today. Put another way: service developers encounter web services and the related standards (XSD, WSDL, SOAP, etc) on a daily basis. By placing web services in an SOA context it becomes very clear that the above example doesn’t do very much to deliver on the promise of SOA services. The importance of designing web services with clean and self describing interfaces (at a technical level) cannot be underestimated and is an absolute must within an SOA context.
How do we do technical web service design to ensure clean and self describing interfaces? Let’s first establish some basic requirements that must be satisfied by the web service design process:
- All service interfaces must be strongly typed and document oriented. This implies that our design efforts will always result in Document style web services. Document style web services align well with message oriented integration initiatives.
- The design must be interface driven i.e the functional contract of the service must be defined in an abstract manner (no implementation).
- The output of the design process must produce the following artifacts:
- Documentation to communicate the service design.
- XSD artifacts that represent the data model of the required service inputs and outputs.
- WSDL artifacts that represent the functional contract of the service.
From a personal perspective I would like to add a few more requirements:
- The design process should encourage a healthy dose of DRY (Don’t Repeat Yourself) . For the purpose of this discussion it implies that it must be possible to take the deliverables from the design process and realise a service implementation*.
- I don’t like authoring WSDL documents by hand and haven’t found any tooling that simplifies this task to be any less error prone than it actually is doing it by hand. The only (and safest) option left is code generation (see the Rule of Generation). The design process must therefor facilitate the use of Java interfaces to define the functional contract of the service and provide tooling to generate the WSDL document**.
Below is a description of the tool chain that will be used to drive the design process and address the requirements.
- Apache XMLBeans. XMLBeans is a technology for accessing XML by binding it to Java types. XMLBeans address requirements 1 and 3(b) by providing full support for XML Schema Definitions (XSD). Full XML Schema support is important because it allows service designs to take full advantage of the power of XML Schema and not have to restrict themselves to a subset of supported features. This does however imply authoring XSD documents as part of the design process.
- JAX-WS. The Java API for XML Web Services (JAX-WS) defines a Web Services API to develop Web Services solutions. Put differently to address the specific requirements (2, 3(c)) of the design process; JAX-WS facilitates the definition of web services using Java interfaces by providing a Java < -> WSDL mapping and a set of annotations to express this mapping.
- Apache CXF. Apache CXF is an open source services framework that implements the JAX-WS specification. The framework provides tools and infrastructure to help build and develop services. In addition to providing a TCK compliant JAX-WS implementation, the framework also supports alternate data bindings including XMLBeans.
- Apache Ant. Apache Ant is used to drive the build process responsible for code, documentation and WSDL generation.
- Javadoc. The Javadoc tool is used to generate online documentation from the XMLBeans and service interface(s) and addresses requirement 3(a).
- UMLGraph doclet. UMLGraph is an optional requirement. UMLGraph provides an alternate Javadoc doclet implementation that is capable of generating UML diagrams for inclusion in online Javadoc documentation.
Now we know about the tools. The image below outlines the design process to produce a technical service design using the tool chain described above.
Let’s step through the process using a very simple example.
A new version of the Java Toolbox open source project is available. Here follow the release notes:
Build 25 (b25)
* Added WS-Addressing, JAX-WS proxy and XmlBeans support to the
** Added the following classes to support interaction with addressing
* Added the toolbox.web.ws.ExportBusCXFServlet class. This servlet extends
the CXFServlet and exposes the Bus instance employed by the servlet
to the rest of the web application through a ServletContext attribute
* Added the toolbox.web.actions.wsil.WSILAction to facilitate WSIL document
* Added share/ant/wsdesign.xml Apache Ant build file to facilitate the
generation of Web Service designs using Java as a DSL. (Experimental)
* Added the DaoWorker::executeCallForOutput() method to perform stored
procedure calls that return more than one output parameter.
* Added DaoBeanEx meta data support to the toolbox.dao.ListBuilderImpl.
* Added an event driven FTP client API. The FTP client implementation is
provided by the Apache Commons Net package. The API is implemented in
the toolbox.ftp and toolbox.services.ftp packages.
* Added two additional DaoBean templates to the templates/dao directory. These
templates will genenarate DaoBean implemenations using static members to store
the bean meta data. This should be more memory efficient and performant.
A client recently asked me how they could go about running multiple SOA service versions side by side in the same (non production) environment, specifically on one WebLogic Server domain. The actual question was more technical and referred to WAR, EAR and SAR artifacts.
Let’s create a service development scenario; We have a legacy application that must be service enabled to participate in an SOA initiative. The application has a quarterly release cycle and the application development team creates a new environment for each release i.e the application is exposed at a different location for each release. Older releases are still available for a period of time to facilitate maintenance. The service enablement team on the other hand only have one development environment i.e new development and older maintenance service releases must share the same environment. We will assume that the service enablement release cycle must follow the application release cycle for the purpose of our discussion.
Getting back to the question. The answer varies depending on how the service enablement is done i.e using stock JEE techniques or Oracle SOA Suite (SCA).
Standard JEE Applications(EAR,WAR):
The service development/maintenance scenario described above cannot be addressed by a native WebLogic Server versioning feature. Running two versions of the same application (war/ear) side by side for an undisclosed period must be addressed using a combination of other techniques e.g scripting and/or deployment plans. In short the JEE artifact must be made available at two distinct access points on the server and this requires some planning and automation.
WebLogic Server does however have a native versioning feature to facilitate production redeployment. This allows an application to be updated with a new version while the older version still processes in flight transactions. All new transactions are directed to the new deployment. As soon as all in flight transactions complete, the older version is automatically retired.
Oracle SOA Suite SCA composites (SAR):
Versioning and the ability to run multiple composite versions at the same time are first class citizens in Oracle SOA Suite. The access points for different versions are handled by the SOA infrastructure and does not require any additional work, apart from assigning a version number to the composite.
NOTE: It is very important to remember that WebLogic Server has no knowledge of SOA composites. WebLogic Server only knows about the soa-infra JEE application. SOA composites are deployed to – and executed inside the soa-infra SCA container.
So, how do we implement this? For the remainder of this post I would like to focus on versioned composite deployments and the use of configuration plans as an example implementation strategy for the development scenario I described earlier.