Business « Design « Java Articles

The most important safeguard against the risk of specification creep, the emergence of more and more demands at the end of a project, is comprehensive specification of the project's subject matter. We can't blame the business experts for not imbibing in documentation and specification along with their mother's milk, so we need a clear idea how to extract from them the information necessary to our project. In addition, different goals can conflict when writing the specification. Time and effort well spent with the specification may reduce the risk of extra costs at the end of a project, but it is an investment of its own right and must be accounted for. Pure monetary investment is not the only issue; the parties involved in the process produce their own challenges: the cell of technology-resistant employees, the able-minded consultant mainly interested in invoice-vindication, an extremely cooperative but perhaps incompetent project leader. Let's at least nail down that cell of technology-resistant employees by adopting the ancient Arabian proverb, "If the camel once get his nose in the tent, his body will follow".

I had the privilege of hearing Mike Hammer speak at a Planet Tivoli conference in Nashville, Tenn., last year. Considered by many to be an expert on modern business thinking, he presented three simple observations that characterize the Internet-based business environment in which today's managers work:

All businesses face increasingly difficult challenges today, as Internet technologies reduce cycle times, increase expectations for quality, and raise the bar with respect to global competition. The message for IT managers today should be clear: IT investments must be strategic. This means that so-called Band-Aid solutions, while less costly in the short term, will have much higher costs in the future.

In developing Web applications, we often see that business flow and logic are implemented together in actions, such as backing-beans in JavaServer Faces (JSF) and action classes in Struts. With the help of existing frameworks, e.g., Enterprise JavaBeans and Spring, we can separate business logic, but business flow remains embedded.

In early 2000, JavaWorld published a two-part series I wrote entitled "The Business Case for Java: A Primer for Geeks," in which I listed the then distinguishing characteristics of both the competitive environment and the Java platform. Such characteristics were germane to a discussion of the strategic merits of adopting Java.

You have now completed the data layer of your application, and are ready to dive into the business layer. If you recall from Chapter 2, the business layer incorporates your application's business logic. Specifically, you will need to provide access to your entity beans, business calculations, and a scheduling facility. In this chapter, I'll detail the access to entity beans already in place, and discuss how to handle more complex business tasks. Chapter 9 then details the scheduling process.

Continuing on with the Forethought business logic, I want to spend some time on the issue of stateful versus stateless beans. I refer to it as an issue because it almost always manages to come up when working with session beans, and can have a drastic effect on your application's performance. Specifically, stateless session beans are much more efficient than stateful session beans.

In addition to data source transparency, designers of complex systems often need to worry about data format transparency. Data format transparency basically means that a client does not have to make distinctions in data that characterize best practices in data storage. In other words, a client does not have to worry about how data is actually stored. The back end can be designed according to the best practices in data storage; the client doesn't know or care about the details. In other words, a client can act logically without having to think physically. Of course, I've been addressing this logical-versus-physical concern for this entire chapter, so there should be no surprises here. Consider that a client will be dealing with a user most often by that user's username (such as gqg10012). However, the directory server and database deal with the user's distinguished name (such as uid=gqg10012,ou=People,o=forethought.com). Forcing the client to worry about that lengthier and less meaningful format is clearly not desired. Your manager components can hide these format details.

Most web and enterprise Java applications can be split into three parts: a front end to talk to the user, a service layer to talk to back-end systems such as databases, and business logic in between. While it is now common practice to use frameworks for both front- and back-end requirements (e.g., Struts, Cocoon, Spring, Hibernate, JDO, and Entity Beans), there is no standard way of structuring business logic. Frameworks like EJB and Spring do this at a high level, but don't help us in organizing our code. Wouldn't it would be great if we could replace messy, tangled if...then statements with a framework that gave us the same benefits of configurability, readability, and reuse that we already enjoy in other areas? This article suggests using the Drools rules engine as a framework to solve the problem.

JAXM provides a good starting point for developing document-style web services that can promote the exchange of information between enterprises in a loosely coupled fashion through context-sensitive documents. Using JAXM, developers can build applications that are a combination of synchronous and asynchronous interactions.

The WorkflowService implementation has been abstracted in eXo Platform version 2. Indeed in version 1, it was dependant of the JBPM BP engine, but in version 2, no reference of any implementation class is used in the client code. Therefore the workflow implementation can still be JBPM but other Business Process Engines can be used. This is currently the work we do with the ObjectWeb Bonita team ( http://forge.objectweb.org/projects/bonita).

Therefore we will first present an overview of what eXo Platform v2 is. We will explain why version 1 was more a portal framework while version 2 is now a core part on which we build an extensive product line that will also target end users. This product line will contain elements such as a Portlet Container, a Portal, a Java Content Repository (JCR ? JSR 170), an Enterprise Content Management (ECM) solution, a Business Intelligence (BI) platform and many more to come.

Being so, this article starts by discussing a proto-pattern called Encapsulated Business Rules. For the sake of simplicity, the pattern will be described in terms of plain Java classes and interfaces. Then, in the Consequences and Related Ideas section a possible implementation using Message-Driven Enterprise JavaBeans will be discussed.

The J2EE Patterns Overview chapter looks at basic concepts behind J2EE patterns, examines the tiers for pattern categorization, explores the relationships between different patterns, and provides a patterns roadmap listing architectural requirements and patterns addressing those requirements. The Business Tier Design Considerations and Bad Practices chapter looks at related design issues when applying business tier and integration tier patterns from the book's J2EE Pattern Catalog.

Whenever I work on an integration or Service-Oriented Architecture (SOA) project, one of the first few steps I take is to identify what constitutes information that the business needs to perform its processes. This business information is what is meant to flow from one service to another and unless I know what each process requires (or what it generates), there is no way to figure out how to make sure that the right process receives the right information at the right time. This business information is different from control information that also flows through systems. Control information can be system notifications or exception messages.

The Open For Business project, commonly abbreviated "OFBiz" (pronounced "O. F. Biz," at least by its founders), has enjoyed great success since migrating to java.net in August 2003. Version 3.0 was released in March, and project founders David E. Jones and Andy Zeneski talked with java.net about the project in April.

OSWorkflow is an open source workflow engine written entirely in Java with a flexible approach and a technical user base target. You can create simple or complex workflows, depending on your needs. You can focus your work in the business logic and rules. No more Petri Net or finite state machine coding. You can integrate OSWorkflow into your application with a minimum of fuss. OSWorkflow provides all of the workflow constructs that you might encounter in real-life processes, such as steps, conditions, loops, splits, joins, roles, etc. (If you are not familiar with these terms, I will explain them in the "Basic OSWorkflow Concepts" section.)

Business objects are often the most important pieces of an application. They are persistent and long-lived, and often have more than one state. At each state, the business behavior may be different. The business logic implementation can become complicated and hard to test and maintain because the business object state transition logic is scattered in the business logic, often using switch statements. The State Machine Compiler (SMC), a Java-based open source tool, can be employed to decouple the business object state transition logic from the business logic. It leads to simple, easy-to-test, and reusable business logic implementations, especially for business object-centric applications.

New techniques have been introduced in recent years to help companies make better use of that data. In this interview with Artima, Colin Gray, Director of Developer Marketing and Americas Marketing at Business Objects, describes one such innovation, business intelligence dashboards:

Even in the simplest case of load-balanced Web applications with session state and servlet architectures, the application servers that cluster session are expensive and the clustering implementation impacts the business logic by violating the language's object orientedness. Java applications would be easier to write and cheaper to run if the Java Virtual Machine (JVM) could be extended through a plug-in, allowing multiple machines to cooperate as one. Clustering at the JVM level this way provides the Java developer with benefits that can drastically speed up his or her work. How drastically? Think crossing the United States on an airplane versus in a wagon train (see Sidebar 2. A Case Study: NTT Results from Terracotta Clustered JVM Solution).

Using a rules engine can significantly reduce the complexity of components that implement the business-rules logic in your Java applications. An application that uses a rules engine to express rules using a declarative approach has a higher chance of being more maintainable and extensible than one that doesn't. As you've seen, Drools is a powerful and flexible rules engine implementation. Using Drools' features and capabilities, you should be able to implement the complex business logic of your application in a declarative manner. And as you've seen, Drools makes learning and using declarative programming quite easy for Java developers.

For many business leaders, software quality is often viewed as a luxury -- something that can be sacrificed, if necessary, for added functionality, faster development, or lower costs. In practice though, successful software development organizations have found that an organizational commitment to quality speeds development, reduces costs, and allows new features to be added with greater ease. How can this be? It is because an organization that develops low-quality software, whether for internal use or for sale, is essentially always looking backward, spending time and money fixing defects in "completed" software. By contrast, the organization that builds in quality from the beginning can be forward-looking, able to innovate, and pursue new opportunities. As an added benefit, delivering quality is a powerful differentiator because today, high-quality software is the exception rather than the rule.

The Java programming environment and supported toolset (provided by the Framework) provide all the key globalization services. The Application Framework for e-business exploits the following Java capabilities to provide an ideal environment for developing and running globalized e-business applications:

Business Intelligence (BI) is a catch phrase that was coined in the mid-1990s to describe taking data from its raw form and turning it into something usable that business decisions can be based on. It is an umbrella term that ties together other closely related data disciplines including data mining, statistical analysis, forecasting, and decision support. Developers should take an interest in BI as BI features are being built into new versions of developer tools and databases. For example both Microsoft (with MS Visual Studio 2005 and SQL Server 2005) and Oracle (with Oracle Database 10g and Oracle Developer Suite) tout BI as important components. And as BI begins to pop up as a job title, part of a job description, or in project specifications, you'll need to know just exactly what it refers to.

We'll begin by reviewing the lifecycle of a business service. This will provide a context for discussing the high-level use cases related to managing services. Each use case will highlight the features of a service management platform that automates the operational aspect of business services. We won't discuss any particular third-party products for managing services per se, but focus on the features such platforms would be expected to support. We'll end with a summary of the major points covered.

In Field of Dreams, Ray's dad, John Kinsella asked him, "Is this heaven?" and Ray said, "No, it's Iowa". "Funny, I thought it was heaven," John responded. Are business services some type of nirvana?

This article will discuss organizing principles of producing and consuming business services that should be considered before publishing a service or utilizing a partner's service:

Sun Microsystems' Lew Tucker is all business these days. The early feel-good era is over and the slog to bring Java into the enterprise battlefield is in full swing. But this is one spokesperson who doesn't mind combat, he welcomes its opportunities.

Figure 1 is an electronic business scenario without ebXML. ACME Manufacturing and one of its largest supplier, Coyote Industries, want to implement an electronic relationship. The goal is to streamline ACM procurement, reducing costs and increasing competitiveness.

Organizations that have adopted these practices are already aware of the significant long-term implications of writing better software. For these organizations, the cost of building software has come down primarily due to fewer failures; and, perhaps most importantly, they are meeting the needs of the business.

In this article, you will design a business rules framework using Java and XML. You will learn what constitutes a good business rules framework design and go over an example that demonstrates how to use the framework.

Current Business Intelligence (BI) applications are programmed to know what information is needed to answer pressing commercial questions such as "Who are our most loyal customers?" They then search the data needed to generate that information.

I've been paying the rent as a professional software developer since the 80s. I've also worked both full time and part time as a musician for longer than that. In my travels, I've come to recognize a great many similarities between programmers and musicians. Both have the fire, passion and soul of the artist. And all too often, both are incredibly naove when it comes to the business end of things. Business - you know, that aspect of your work where they actually pay you at the end of the day?

Business intelligence applications look at the information needed to answer these questions and then search the data needed to generate that information. The resulting answers can be optimally targeted throughout an organization via an interface allowing users to explore the data from different perspectives.

An interesting separation of concerns is becoming possible by the use of BPEL. BPEL (Business Process Execution Language) allows for business process logic to be expressed in a specific language and to be tied into external software. This reduces (and potentially eliminates) the need to code business process logic in a traditional programming language (such as Java or C++/C). In turn, this provides a clear separation between software features and business processes. By taking the business process logic (e.g., workflow management) out of the application code, the latter becomes simpler and more focused.

One of the questions I get asked a lot is about business rules relationships to expert systems. Expert systems, after all, have a bad rap in many areas thanks to complex setup and poor performance. What, then, is the difference?