How can we satisfy a programmer's need to develop software using new technologies as well as the need for saving application server versions within the systems sector? IBM has the solution: WebSphere Application Server Feature Packs. Feature packs, more commonly known as modernization packs, extend the lifespan of versions of the application servers and result in the necessary technological upgrades. For example, many companies still use the WAS 6.1, which is a four year-old version. In the world of software, this is a very long period of time which would not be possible otherwise without modernization through the feature packs. Meanwhile, the correct 7.0 version has acquired several interesting modernization packs. Much has been done over the last two years since the release of the 7.0 version. Firstly, a few standards have been completed, each one in its own way, which have made the development easier and which present the best programming practices. The standards that will be discussed include: OSGi Service Platform Enterprise Specification Release 4 version 4.2, JPA 2.0 i XML standards XSLT 2.0, XPath 2.0 i XQuery 1.0. Support for all of the aforementioned standards can be found in the two modernization packs which will be presented in this document.
Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0
OSGI
Most of today's software solutions are used by a number of libraries for fulfilling business needs. This method of implementation is considered good practice. However, new obstacles are presented. Third party libraries are grouped together with a well-developed executable code in the archive which is sent for deployment. Since, in most cases, we have more copies of the same library, this results in suboptimal use of application server resources. Duplicates use up OCCUPY expensive working memory and disc space. In an attempt to resolve this problem, we can deploy two applications as three separate modules: two modules with executable codes and one with shared libraries. In other words, this is the conceptualized idea of OSGI specifications.
Differences in terminology are present; thus, in the OSGI environment, we refer to these modules as bundles. Bundles describe interdependence through the packs that they import and which are exported to the OSGI environment. In this way, our two applications are installed as three bundles, while detection and linkage of mutual dependence is left to the OSGI environment. This mechanism (and others involved) has to a great extent solved the problems commonly known as JAR hell. In fact, aside from its name, the OSGI bundle also specifies the library versions that are required for the functionality of the module. This enables the deployment of more versions of the same library without the problem perpetrated by interdependence.
Interrelated bundles in the OSGi environment
Service registry
Aside from the library, the OSGI environment enables the functional linkage of servers. Registration, detection and consumption of Plain Old Java Objects (POJO) services from the second bundle is possible through the service registry. Given that OSGI enables the installation, linkage, and activation of the bundles without reactivating the container alone, it is evident that this mechanism allows for component development of software solutions. It is up to the programmer to note the code and pack it in one software solution bundle (data, integration, or presentation) while the OSGI executable environment is responsible for linking the bundles with the necessary libraries and services.
Architecture of OSGi container
EAR Conversion in the OSGI bundle
You will be happy to know that the standard (JEE) web-application can be converted into web application bundles (WEB) in quite a simple way. Changing the file extension from .ear to .eba and importing it as an Asset into the WebSphere® Application Server is sufficient. This is enough to start with, but for full utilization of the OSGI container's capabilities it is necessary to design a software solution through interconnected modules.
JPA 2.0
Mapping projects in a relational model (database) is one of the first tasks facing a Java enterprise application. Traditionally, this task is done with the help of JDBC specifications which abstract differences in relational database implementation. In cases where there is a greater demand for productivity and flexibility, incurring less control over SQL inquiries, JDBC is not sufficient. A more modern and increasingly popular way of working with databases is by using programming tools for project-relational mapping. The Java standard programming environment for mapping is defined by the specification JSR 220, while the standard known as Java Persistence API (JPA 1.0) WAS 7 comes with implementation specifications. Because the first specification version does not cover all instances of use, a supplement (NADOGRADNJA) to version 2.0 was recently created. The modernization pack WAS-a 7 and OSGI support create JPA 2.0 support, which is not unintentional. In fact, as a part of the OSGI enterprise specifications, a special kind of Persistence and Client bundle i defined. This allows for the implementation of the Persistence bundle using JPA 2 technology and its deployment in the OSGI container so that other (Client) bundles are able to use them in situations requiring work with the database.
New Functionality of JPA 2.0
For projects that already use JPA or for those that are in the design phase, switching to the 2.0 version should be considered for the following reasons:
Improved support for complicated situations like embeddable objects and arranged primary keys.
API Criteria query—Enables Java and all other benefits of the development environment to be used instead of entering free text searches.
Feature Pack for XML
Can you recall any new applications, whose development you contributed to, and which do not use XML in any segment? I cannot. Today, in the world of SOA, XML is actually a standard for the exchange of data via wire format. You will, as a result, agree that it is vital to be able to use the latest W3C XML specification standards. The Feature Pack for XML in WAS 7 provides support for the following standards:
Extensible Stylesheet Language Transformations (XSLT) 2.0
XML Path Language (XPath) 2.0
XML Query Language (XQuery) 1.0
These three standards are inter-connected. XPath is used in XSLT 2.0 transformations, with a XQuery 1.0 subset specification. Given this, support for these three specifications is provided in the pack. Support for all built-in types of XML Schemes and a larger number of new operators and functions is also provided with the XSLT 2.0 support. Regardless of whether or not we want to transform a document using user-defined functions or into multiple output documents, this is now possible. XPath is a standard method used for extracting specified elements from XML documents. This is a rather common task today. Version 2.0 gives access to a larger number of operators and functions. In this way, operations that were made difficult using XPath 1.0 or that were impossible using Version 2.0 are now made simple. For more complicated scenarios, which have been difficult to resolve without Java programming, the feature pack provides implementation of XQuery 1.0 specifications. XQuery is a syntax language which includes XPath and similar SQL's. It will be used frequently as a language for extracting data from the XML repository, just like SQL's work with a relational database. Actually, DB2 v) supports XML-type data together with XQuery as a language for manipulating information. As a result, support for XQuery and WAS is welcome since it makes working with information in XML format easier.
Tools must also be noted. The development of solutions to be used by the Feature Pack for XML is furthermore supported in RAD 7.5.5.1. It is also possible to debug XSLT 2.0 transformation, which RAD places before similar tools. Support for OSGI and JPA 2.0 is accessible through beta Rational Application Developer 8.0.
The aim of this short summary of the modernization packet for WAS 7.0 was to familiarize you with the technologies that are becoming available and which will hopefully speed up software development solutions. This is the time OSGI, JPA 2.0 and XQuery technologies. All you need to do to be able to use them today is download the feature pack archives from IBM's website and install them on your already-installed WAS 7.
In one of our last FYI issues you could have read an article on a specific portal solution. The article comprised a detailed introduction into a historical development of the portal as a concept, and gave an overview of the most important representatives of portal solutions as well as an explanation of their main purposes.
Not to have our dear readers overwhelmed with déjà vu all over again, here we will concentrate specifically on one branch of the portal solution family, and these are enterprise portal solutions, i.e. portals. These solutions are a foundation for designing enterprise portals which provide an easier, more consistent way for meeting requirements of big organizations and companies with complex business and specific technical needs. The core of every enterprise portal is a program framework for the integration of information, business processes and people. Integration abilities of portals are provided through a unique and secure, information, document, application and other resources option-rich access point, through logical organizational units –portlets. Typical tasks performed through portal interfaces include collecting, publishing and maintaining information and documents as well as development and publishing of specific business applications that help in daily lives of an organization or a company. Tasks and usage cases listed in this way are covered by all or nearly all portal solutions, however, as the focus and the portfolio of CROZ, in majority of company’s implementation experiences, come down to two solutions, we will concentrate on displaying the possibilities of and comparing these solutions. It is about an open source solution called Liferay Portal and IBM solution called WebSphere Portal. Both solutions will be presented through the most important tasks they are challenged with in everyday work, highlighting similarities and differences between them. Also, advantages and disadvantages of both of them will be presented with the aim of making it easier for potential users to decide which solution better addresses their needs. Typical tasks that will serve to reflect the possibilities of both platforms are content managing and publishing and development and publishing of specific business applications. Therewith, we will not forget the key points which make enterprise portals what they are:
· Single Sign-On (SSO)
· Personalization and Customization
· Access Rights Management
These key elements are brought to perfection by each portal solution and there are no major differences in different solutions’ approaches. Thus, it is relevant to point out the areas already mentioned, that make the solutions at least slightly different, if nothing, in their final performance and impression.
Sesame Street Liferay Portal
System Room Perspective
Before we get to talk about document management or specific business functionality development, let’s take a short look at basic system requirements that are necessary to set Liferay and WebSphere Portal up for production operation. Even in other environments, starting from developmental one, the need for resources is substantial, but production environment will serve well to illustrate the needs. As both solutions are actually JEE applications whose running depends on the presence of JEE applicative server, it is obvious that they can be run on almost any available platform, starting from Microsoft Windows platform, any UNIX based platform, and even z/OS platform. Having this in mind, it is necessary to underline that both solutions are considerable resource consumers. The WebSphere Portal solution installation itself will make an impact on the disk subsystem, knowing the fact that minimum 4 GB disk space is required for the installation. Regarding this, Liferay Portal is much “softer” – up to 500 MB disk space is enough for the installation. As the amount of data that are maintained or stored using one solution or the other grows, so does the consumption of disk space used by data bases and document repositories to which data and documents are stored. As for RAM, both solutions in production environment will be satisfied if you ensure 4 GB per processor and single their data base servers out on a separate hardware.
Miami Dade – WebSphere Portal
Liferay and WebSphere in the World of Document Management
Key life (daily or longterm) processes of every serious organization and company include working with large amounts of various documents, or better said large amounts of various information. It is clear that portal solutions did not “invent” document management processes program support, however, as the central integration point of the whole of organization, the portal solution is ideal for ensuring consistent management of important (or all types of) documents. What are typical requirements for document management? Document management, weather it includes Portal or not, is based on a document repository, creating document management processes (document workflow) and document and process management interface. In order to compare the two portal solutions, we will take a look at the three document management bases just mentioned. Here, I have to point out that, perhaps, some of the observations related to the document management interface are my personal observations, but this is almost always the case when we deal with application interfaces.
Document Repository
Any document management solution that is fairly serious is developed around a quality repository. Also, if the solution is based upon a JEE platform, the repository will be developed on the bases of JSR-170 specification, i.e. it will have the characteristics of Java Content Repository specification. In this, the two solutions do not differ much – Liferay Portal uses Apache Jackrabbit JCR implementation, while WebSphere Portal uses its own implementation of the same standard. Take note that the implementation used by Liferay Portal is better documented, thus ensuring easier adding of specific functionalities if needed.
Document Management Processes
Both solutions dispose of the possibility of document management process customization (document workflow) that will satisfy the majority of business requirements. Although Liferay Portal has slightly more flexible process model, the differences are hardly visible. Both solutions have standard roles defined, which participate in document management process, and the customization gets down to accurate definition of the steps of the process through which documents are pushed from the time when they are developed until their publishing and maintenance.
Document Management Portal Interface
The interface also shows similarities between Liferay and WebSphere Portals, but only due to the fact that both solutions offer the same functionality – document management. The interface (as a whole, not only the document management part) is a Liferay characteristic that makes it brilliant. It is distinguished by intuitiveness, serviceability, clear underlining and pointing out of important information and available actions. In a nutshell, usability is on an extremely high level. The Liferay Portal solution development team produced a dynamic and rich, yet simple interface. WebSphere Portal lags somewhat behind, although, compared to previous versions, the interface is much better. As I have mentioned, the observations set forward are probably personal, thus it should be pointed out that WebSphere Portal has very functional document management interface, matched with the rest of the portal’s interface, and will enable the user to perform desired sequence of actions, but the final impression is not that good or positive. Perhaps it would leave a better impression if the other solution did not make a fantastic one.
Possibility of Extension
Comparing the two, one must surely have in mind the extension of IBM solution that can easily “lean” on the best document management system currently on the market, IBM Filenet. In case of such a symbiosis, WebSphere Portal actually becomes just an interface that opens the view towards Filenet, which offers numerous possibilities and functionalities in document management process adjustment. Liferay Portal can also be extended, if desired, by a single document management solution, such as an excellent open source Alfresco solution, nevertheless, IBM Filenet is currently top ranked, and the combination of WebSphere Portal with Filenet solution offers a maximum set of opportunities in the world of content and document management and publishing.
General Impression
Document management, to tell the truth, is monotonous and slightly boring task information systems, i.e. their components have to deal with. Like task, like solutions. There are no big surprises when it comes to WebSphere and Liferay Portal. Set up document repository, customize document management process, grant people rights to participate in the process and use built in document development and publishing interface. You can do all of that in a more simple and faster way with the Liferay Portal solution, which is more functional for typical usage, however, if the amount of documents or process complexity increases significantly, the WebSphere Portal extended with the IBM Filenet solution makes a better choice.
One More Portlet, Please
If you need to additionally empower an already powerful platform (which Liferay and WebSphere are) with particular business functionality, the easiest way to do so is to develop portlets according to functional (and nonfunctional) specification the implementation team is challenged with. Both portal platforms offer a wide variety of possibilities that will make your job easier and support almost authentic selection of developmental technologies. With a great difference, though. Systematically, WebSphere is rather demanding and challenges the development team with the task of setting up a developmental environment that will make portlet development quick and easy. This may include development in a different environment (Apache Pluto or JetSpeed, Oracle OpenPortal, even Liferay Portal) or lifting WebSphere Portala up as a developmental environment, which implicates purchasing fairly strong developmental computers. Liferay, on the other hand, does not set system requirements that high, so it can be used as a developmental environment without having it customized a great deal. Let’ s take a look now at the most important personal portlets’ developmental technologies (details of which can be seen in the framework appended to the text) and see weather WebSphere Portal and Liferay provide support for them.
JSR-286
Both portals support the newest portlet specification, which is of extreme importance for the development of modern portlets of new generation.
JSR-186
Of course, previous portlet specification is still available for simple portlets, which is also recommended for smaller “interventions” and portlets which do not need AJAX functionalities.
JSR-314
JSF technology becomes ever more popular, and for a reason. JSF implementation performance problems have been eliminated, and a new, JSF2, specification has been released. It promises advantages, among other, a faster, simpler and more standard interface development, performance improvements, better developmental tool support. This is where WebSphere Portal shows no brilliance – it lacks JSF2 “out–of-the-box” support, however, with some adjustments, one can also develop JSF2 portlets. On the other hand, Liferay already provides support to JSF2 portlets.
And the Best Portal Award Goes To…
There is no award winner in this contest, and there cannot be one. Why is that so? The statement from the beginning of this short story is still true; the two solutions are quite alike from every point of view. Liferay Portal solution user interface is slightly better, nicer and more intuitive to work with. WebSphere Portal is a more extendable platform, with a wider usage range, especially if combined with some of more specialized IBM document management solutions (Filenet) or processes (Process Server). If your requirements do not ask for enterprise environment, Liferay Portal is free and has no support outside the Liferay forum and wider Internet area. Using Liferay solution in this way makes sense for educational, research or personal purposes. If there is a need for any serious usage case, you will definitely go for the implementation of Liferay Portal solution along with paid and highly accessible expert support which is immediately available with WebSphere Portal solution. In their current versions (Liferay Portal 5.2, WebSphere Portal 6.1.5.1) both solutions have reached an enviable degree of maturity and problems appear rarely, but are always possible, thus working without professional support seems almost impossible. CROZ teams’ experience with the implementation of the solutions based on both platforms are generally very good and there has been no need for pulling that little hair we have. Our reference in choosing certain platform is always based on the intense cooperation with users in order to be able to define their needs and help them in that the final solution based on one of the Portals is exactly what they want and need, and in the end, to use it with pleasure and as longer and easier as possible.
IBM Lotus Software delivers robust collaboration software that empowers people to connect, collaborate, and innovate while optimizing the way they work. With Lotus you can drive better business outcomes through smarter collaboration.
The platform solution is aimed at middle and large organizations that wish to work systematically on the informatization of their business processes. In its core, cDocs is a business process and document management platform that comes with several default modules: Inbox, Outbox, Internal mail, Contracts, Accounts, Payments/Payouts, but also with the possibility of developing support for new and specific business processes. Our experience in business analysis helped us to customize the existing modules to suit as many out-of-the-box users as possible and modular platform enables us to completely adjust the existing modules as well as the new ones to your specific requirements.
When projecting a platform and a module that make a quality product, it was our intention to provide the maximum preservation of the investment made in IT knowledges and technologies and to prevent users from being limited to using non adjustable formats. Furthermore, the idea was not to bring additional license expenses to future users; therefore, at the very beginning we decided to integrate the most quality open source components and to develop a module on such open platform.
This is exactly the reason why the core of the system contains Alfresco Document Management System and JBoss jBPM platform for Business Process Management. Alfresco DMS is a product of Alfresco Inc. and presents a leading open source document management system. Excellent record and user scalability make the cDocs platform limitless in this sense, and our references can prove so. Alfresco, thus, in cDocs enables document capturing, storage, transmission and distribution. jBPM is a JBoss Inc. product and, again, a leading open source system for business process management.
Besides the integration of open and open source components, CROZ’s cDocs solution is based on publicly defined business process management standards – jPDL and BPEL, which means that we can project your business processes with tools we grew accustomed to, and the same goes for your business analysis departments. In case you already have the processes in BPEL language, we can build a modular IT support for their management very quickly. Also, the processes that are described and implemented in cDocs modules can be performed and analyzed in specialized tools. This one is a good team player, and we are very proud of it!
cDocs is an upgradable and robust solution, and these characteristics derive from its two key architectural components – CROZ ECM (Enterprise Content Management) platform and module system.
ECM platform is the essence of the solution and takes care of defining and performing processes, process and document life cycle, users rights, notifications, calendar, record management (scanning, digitalization), data mining and other “mechanic” work. ECM platform is the engine of this solution, a reliable and tested one, with long life duration. It has been tested on dozens of millions of documents and thousands simultaneously active users, and can also be scalable in view of thousands of documents and dozens of users.
The module system enables effective support development for specific business processes and is a steering wheel of this solution (apologies for this lame comparison with a motor vehicle; we are better in developing solutions than writing :-)). Having great number of options and abilities, as well as the ability to adjust to concrete requirements of the organization that will implement them, the modules that are delivered together with the product are customized in the way they suit as many users as possible. All new modules are developed in accordance with open standards together with business analysis department, and after having documented the process, in cooperation with a client.
Some of the most important characteristics of the solution are:
- robust, powerful and flexible platform for process and document management
- ready-to-use group of modules prepared by CROZ’s business analysis department, with the possibility of customization
- quick and efficient preparation of new modules under unified platform, very short time-to-market for additional processes
- notification system completely integrated with the process calendar which notifies users in background about their duties related to processes, and serves as a reminder on missed events and expiration dates
- excellent integration with solutions for digitalization and capturing: Kofax, Kodak, Abby and other
- integration with reporting systems such as data platform and integrated flexible reporting system
- reliable event history
- flexible and secure user rights system with the possibility of integration in Lotus and Active Directory authentication systems
- integration in various IT environments, work with virtualized systems and different data bases, and different operating systems
- integrations with Microsoft Office, OpenOffice, Windows Explorer, Mac OS
References received so far have confirmed our choice of architecture and determination towards an open system, and even if we would start it all over again we would have made same decisions. Some smaller challenges related to certain components were corrected along the way by our mechanics and toolpushers, and we shall keep the steering wheel of production on this way also in the future. Additional modules and integrations will be included in the offer with special focus on speed and simplicity of system usage. Satisfied with the accomplished, we hope that our users will recognize our effort and daylong work alongside factory sirens.
IPsec is a group of protocols used on top of IP for the purpose of authentication, encryption and secure exchange of encryption keys. These three activities correspond to three different protocols. The Authentication Header protocol, or AH for short, confirms the identity of the sender. Packet encryption is done by Encapsulating Security Payload or ESP. Finally, Internet Key Exchange or IKE is a mechanism for exchanging secret encryption keys used by ESP.
There is also an additional protocol, Payload Compression Protocol (IPComp). As it is next to impossible to achieve efficient compression of encrypted data, IPComp accommodates this shortcoming by compressing packets prior to ESP encryption. So while IPComp isn’t essential for actual security, it is essential for efficient net usage.
With the exception of IKE, all protocols are implemented somewhere in the depths of the Linux kernel. IKE is usually run as user-space daemon. There is an abundance of IKE implementations and there is always an option of putting keys manually.
As a part of the IPsec stack within the Linux kernel there are two databases. They are named Security Policy Database (SPD) and Security Association Database (SAD). Strictly speaking, those two databases look more like two tables than anything like relational databases, but nevertheless they do store data which is vital for IPsec functionality.
SAD stores Security Associations (SA). SA is used as a description of encryption protocols used on IPsec packets. The best analogy to describe security association would be a recipe. Just like a recipe is a list of directions and a set of ingredients for making something, SA is a mixture of directions and ingredients for the encryption of IPsec packets. With SA one can indicate the encryption of the authentication header and of the payload, and the encryption algorithm to be used for both of these tasks.
Like an unused recipe, unused SA doesn’t mean much. The purpose of both becomes apparent with usage. Security Policy (SP) is a mechanism which will put SA to the desired use. SP describes IPsec security procedure for a connection. SP can designate a host or port connection. Once a policy is set for a connection, the kernel will determine which security associations to apply to that connection. Security policies are stored in SPD database.
XFRM
This simple overview of IPsec functionality raises a new question: how to use all those mechanisms within Linux? The end user will probably be satisfied with running an IKE daemon and a front-end through which one can insert all the associations and policies in the kernel. A more advanced user can achieve a similar effect through command-line utilities like setkey or iproute.
As this article is aimed at the most advanced users—the programmers, the population for which “how to use” is an abbreviation for “how to use it from code” things get more complicated. That question is by an order of magnitude harder. To answer this, additional insight into the kernel is needed, to the point where we must introduce a part of the kernel known as XFRM.
Both SAD and SPD are handled by the kernel module known as XFRM. Upon request XFRM will add, get, update or delete entries from SAD or SPD databases. Communicating with XFRM the programmer handles the SAD and SPD databases. Communication is done by passing messages to XFRM. It is also bidirectional. XFRM passes similar messages to the programmer. This happens when some triggered event fires, or more usually as a response to a programmer’s action.
XFRM is located deep within the kernel and it isn’t directly visible to the programmer. It is also an undocumented part of the kernel. The standard way of the communication with XFRM is done trough the Netlink Sockets API which is the standard IPC mechanism for various parts of the kernel. More specifically, the part of Netlink of our interest is NETLINK_XFRM. Unfortunately, that part is complex and also undocumented. An additional API does exist. It is called rtnetlink and is a wrapper API for netlink. It is somewhat easier to use and it is somewhat documented. It is a part of iproute2 project.
Inserting simple Security Policy
The simplest way to add an SA or SP entry is trough command-line utilities like iproute or setkey. We’ll be using iproute. For the list of all functions possible on policies use:
$ip xfrm policy help
Iproute is capable of adding, listing, flushing, deleting or updating policies in the database. The simplest way to add one policy would be:
$ip xfrm policy add dir in
This will add one general SP to SPD. The analog way to do so in C would be this:
The code is very simple. A quick explanation follows. In the first line we created an rtnetlink handler. Rtnetlink will take the burden of handling netlink sockets and this handler is used as a marker to those internal structures. That’s all there is to it. A more important part is the creation of the request. It is a structure composed out of three distinct features:
a Netlink message header
an XFRM message
a field of attributes (that 2k char buffer)
All netlink messages consist of the netlink message header (nlmsghdr) and data which it encapsulates. The netlink message header carries some general information about the message like its type or size. As our goal is to add policy to SPD, the message we’ll use is of type XFRM_MSG_NEWPOLICY, which is defined in linux\xfrm.h.
This type of xfrm message is associated with the xfrm_userpolicy_info structure which carries all important data about a policy. It is a quite complex structure because the policy carries quite a lot of information. But for now, as our goal is simple (adding the most general policy), we’ll ignore all those things. Just remember that when you need to add the port, the destination or source address, the way of tunneling, the transport protocol and many other things you’ll add it to xfrm_userpolicy_info. The things we have set here are the expiration times of the policy (which we set to infinity), IP4 as the transport protocol in use (AF_INET), and the direction of the policy to “in” (XFRM_POLICY_IN) as this is default. All these constants are defined in linux\xfrm.h.
The field of attributes is not used in this particular example. However, it is used in more complex tasks like sending a provisional number of policy templates etc. The field of attributes is a standard part of the netlink philosophy, and meant to be handled by RTA macros within netlink which take the burden of proper memory alignment and can’t really be described as the most intuitive thing in the world. After all, this is low-level system programming
The last step is opening a socket (NETLINK_XFRM socket), sending the request, and closing the socket. Upon failure the code will stop. That’s all there is to inserting a new policy into the kernel.
Success of this function can be seen by the use of:
$ip xfrm policy list
The flushing of the policy is done with a very intuitive command:
$ip xfrm policy flush
The actual working code with all the needed headers and such is present here. In later articles we will demonstrate somewhat more complicated handling of security associations and polices, and some general lines of xfrm internals like a general walkthrough of all types of messages and associated structures.
Hibernate offers us three basic ways to map class inheritance to relational database:
1. Table per class hierarchy
2. Table per subclass 3. Table per concrete class
Each of these have it's strengths and limitations and we will make short review of them and present simple examples based on following class hierarchy:
public abstract class Animal {
private Long m_id;
private String m_name;
private BigDecimal m_weight;
public Long getId() {
return m_id;
}
public String getName() {
return m_name;
}
public void setName(final String p_name) {
m_name = p_name;
}
public BigDecimal getWeight() {
return m_weight;
}
public void setWeight(final BigDecimal p_weight) {
m_weight = p_weight;
}
}
public class Bird extends Animal {
private BigDecimal m_wingsSpan;
public BigDecimal getWingsSpan() {
return m_wingsSpan;
}
public void setWingsSpan(final BigDecimal p_wingsSpan) {
m_wingsSpan = p_wingsSpan;
}
}
public class Dog extends Animal {
private BigDecimal m_lungsVolume;
public BigDecimal getLungsVolume() {
return m_lungsVolume;
}
public void setLungsVolume(final BigDecimal p_lungsVolume) {
m_lungsVolume = p_lungsVolume;
}
}
public class Fish extends Animal {
}
1. Table per class hierarchy
In this mapping approach we map whole class hierarchy to one database table. It's main feature is it's simplicity, we can read/save our object in just one table and there is no need to multiple create/update sql statements (when we save or update object) or join on multiple tables (when we read object). Main weakness of this approach is that we can't have NOT NULL constraint on any column mapped to property declared in any of subclasses.
In this mapping approach we map properties contained in base class to one database table and properties contained in each subclass to it's target table. This way for hierarchy of one base class with three inherited classes we have four tables in database where each of tables mapped to subclass is connected to table mapped to base class by foreign key. Weakness of this approach is that we have more complicated database schema where it is more difficult to follow object in database. Strength of this approach is that we can use NOT NULL constraints to ensure integrity of all properties from subclasses. This is mapping where database structure closely follows object hierarchy.
In this mapping approach we map each concrete (non-abstract) subclass to one database table. Therefore we don't have to have database table for abstract root class and we have reduced number of tables to three and as result we can easily find all data for each concrete object instance in just one place in database. Problem with this mapping is that we have "column duplication" in database (for each field in base class we have column in subclass table).
Before deciding which mapping to choose we have to take close look at our domain model and distribution of data (fields) through model (classes). One (extreme) case is that all properties are contained in our root class and we have subclasses used only to differentiate types of base class and to define different behaviour for each specific type. Another (also extreme) case is when we have base class used only to semantically mark kinship of our classes (and maybe define common behaviour) but all data (fields) are contained in subclasses.
First case would be ideal case for "table per class hierarchy" mapping and second case would be ideal for "table per concrete class" or "table per subclass" mapping. Of course, our problem will most often fall somewhere in between these two extremes and we will have to decide which approach should we take by weighting importance of NOT NULL constraint usage in ensuring our data integrity (if any property mapped to subclass is mandatory) versus simplicity of database schema (and relying on application to ensure our data integrity). Rule of thumb would be that for domain model where most data are contained in base class we would prefer to use "table per class hierarchy", for model where data are evenly distributed through base class and subclasses we would prefer to use "table per subclass" and for model where data are mostly contained in subclasses we would prefere to use "table per concrete class" or "table per subclass".
Hibernate offers use some additional mapping alternatives and it is possible to use combination of different mapping approaches for same class hierarchy. To get more information on this topic check Hibernate reference documentation.
One of the projects CROZ is currently participating in is dedicated to the production of Rich Client Application. Eclipse Rich Client Platform (Eclipse RCP) has been chosen as a platform for the production of client, whose main characteristic is that it enables XML configuration of user interface. The platform automatically manages various visual elements such as menus, toolbars, view or editor frames etc. User of the platform (or rather developer of the application) should concern himself with only the key business certain element is performing – for instance, about the action which should perform when selected from the menu or about the content of the view frame. The platform takes care of the rest – for instance, concerning the frame, its positioning and size, opening/closing, minimum/maximum, docking, stacking and so forth. That speeds up the development considerably and it is a lot easier to maintain the consistent look&feel of the application. In XML configuration of user interface it is customary to name the class which attends to a particular visual element. Your typical configuration element example:
The basic work mode shows that the platform is controlling class instantiation and instance configuration, therefore the user has the command, via XML configuration, over only those class aspects which emerge form its role of visual element controlled by Eclipse RCP. For instance, it is characteristic that the class for the view frame will have dependencies on some sources of data which needs to be visualized. For all such things the class author is left his own devices. On the other hand, CROZ already has the tradition of exploiting Spring’s IoC object configuration, thus it is only natural that there should be a need for a solution which will enable control of the instantiation and object configuration to be moved from the Eclipse RCP to Spring’s IoC container. Fortunately, Eclipse RCP practices Factory Object approach – if there is a class name in the XML which implements the appropriate Factory interface, RCP will instantiate that class and then let that instance create the final object which controls the visual element.
Another important characteristic of the platform Eclipse RCP is that it enables modularity of application above the level offered by Java language itself. In fact, precisely that modularity is the main motivation for the adoption of XLM configuration. Basic approach is as follows: RCP itself is made of a module set (Eclipse term for “module” is “plugin” which we will use hereafter) of which for example, one is intended for managing visual elements. He declares extension points for each element category, for instance, the views point for view frames. Plugin developed by a platform user defines its extension for that point by stating its class name and other criterions concerning frame display in XML configuration. By the very addition of his plugin to the plugin set which compiles the application we can accomplish that it contributes its visual elements to the application without having to write the control code in Java.
The requirement for modularity of application is reflected on Spring configuration as well. It is obvious that one cannot build the entire application context in a centralized manner because that would mean how a certain “main” plugin should know beforehand about all the other plugins and about the configuration of their respective objects. Thus, each plugin should have its own context but it is preferable to be able to connect that context to some common, universally defined context which would contain objects of greater significance for the entire application.
We found an open-source project on the web [1] (we shall name it ESpring) which enables answering of these questions in a rather sophisticated style. The project in question was in a relatively rudimental state and was more of a proof-of-concept than a finalized product so we needed to finish it and de-bug it a great deal, however the key ideas remained untouched.
The project is composed of a single plugin which declares its extension point. Application plugins join their extensions to this point in order to contribute their application context to the central context register. The context is inscribed in the register under an ID defined in the extension. When producing its application context plugin can by ID ask ESpring for an arbitrary second application context to be used as its parent. Example of extension definition for ESpring:
All registered contexts are available anywhere in the Eclipse configuration database plugin.xml, where one customarily states the class name of the visual element. Instead of the class name of the desired object, we state the particular class name of the ESpring plugin, which in turn implements Factory interface and will deliver the object configured in the application context to the platform:
Now comes in another important ability of Eclipse RCP without which this approach could not have become a reality: after the name of Factory-class we can add a colon and a string behind it which will be forwarded to the instance of that class. In this way we can transmit key data necessary for Factory to locate the appropriate application context and the object within it.
With a careful analysis of the described solution’s architecture one could complain that the creation of the application context has been unnecessarily complicated: it not enough to state just the location of configuration database but one needs to create ApplicationContextContributor class which does the creation of the application context itself. The reason for that is the above mentioned modularity of RCP plugins “above the level offered by Java language itself”: namely, one plugin can see only those classes of the other plugin which it explicitly declared to be “public”. Therefore it is necessary that the creation of application context be done by the class of the client plugin.
[1] Neil Bartlett, project „Eclipse RCP Spring Support“, http://sourceforge.net/projects/eclipse-spring
