Application Structure Revisited


There are many things to think about while constructing an architectural solution for your organization. The combination of J2EE, web services, and the extensions to these capabilities made by the WebSphere Application Server provide a powerful set of tools on which to build your application architecture. This section will describe some basic architectural principles for applications that are aimed at utilizing the underlying run-time capabilities of WAS and allow for solving business problems in the most expedient fashion.

Architectural Origins and Evolution

J2EE applications that run on the application server, especially the first applications produced by an organization, generally start out as either web-based or business component-based. Web-based applications often start out as a set of servlets and JSP pages that do some rudimentary interactions to a backend system. These applications probably originate as part of web-enabling activity. They frequently evolve towards applications that leverage EJBs for encapsulating backend functionality and creating reusable pieces of business logic.

Applications that start life as component-based are those that solve a business problem that may or may not require or support a web-based interface. These applications can be EJB-based on the server and driven by the J2EE client via RMI-IIOP inbound calls. In fact, these applications are usually easy to adapt and to put additional interface layers on as technology evolves and the business demands change. This is because they already have a stronger separation of the business logic, presentation logic, and data logic.

In either case, we arrive at an architecture that ultimately captures a business model. A business model, in the most traditional sense consists of a set of entities and a set of processes that leverage the entities. It represents either how the current business functions or some future desired state. Business Process Modeling is about creating the business model. Business Process Reengineering is about changing the business processes to be more efficient, effective, automated, or "better" in some way, shape, or form.

Notice that the first definitions of a business model provided above really do not talk about software as much as they do business. This is a key fact and must not be lost sight of as we go forward in this discussion. Ultimately, this is about business, not technology. We will represent and capture the business model in software, but must be driven by the business as we do this, not by the software. This requirement demands that the software infrastructure ultimately is able to capture and represent the business model in an almost effortless way.

Let's go back to the software architecture and explore how to capture and represent business models in software. Enterprise applications include business functionality and an apprpriate means for users to interact with that functionality. The simplest view of an application architecture suggests that we have a presentation layer and a layer which represents the business model, as shown below:

While the diagram appears quite frugal now, we will be expanding on it through the rest of this section.

Implementations of business models have been done in many ways over the years. We have used relational technology to represent the business entities. We have used data-flow and state modeling to graphically capture and subsequently generate software that executes the processes and sub-processes. This separation of the "flow" and the "entities" is very old. There has always been the "data-flow" crowd, the "everything is a state-machine" crowd, and then the "third normal form entity" crowd that would implement most of the business in stored procedures and relational databases if they ruled the day.

All of these styles and others have been practiced successfully for certain kinds of applications. Each of these styles has come with challenges and has given rise to newer and more improved models for development. Object-oriented techniques and component models owe a lot to these early software development methodologies.

J2EE, through EJBs, contains a modern component model for representing both the entities and the "flow" or tasks (session beans) that would be used to implement the business model. While still lacking enough capability to directly translate from the business model to software model, J2EE represents a rich and modern platform on which to implement a business model in software.

Many modern business model implementations expose themselves to the Web and let customers do business through the Web. Simple web presence initially involved static pages, and then evolved towards dynamic content creation via CGI. This gave rise to servlets, JSP pages, and now portals. Presentation now includes web browsers, as well as pervasive devices.

The figure below shows that we have placed some of the J2EE artifacts into our basic structure:

J2EE 1.3 brings a bit more to the table when it comes to accessing and managing the business model. The following diagram shows that we have filled in the picture a bit more, adding in access to backend systems and the ability to take work requests, based on an arriving message.

Some of the J2EE 1.3 enhancements over J2EE 1.2 do not involve major new building blocks, but rather evolutions of existing building blocks. Servlet 2.3 and EJB 2.0 are just two examples of existing architectural components that are maturing and evolving. While JMS did exist prior to J2EE 1.3, the emergence of message-driven beans in EJB 2.0 and the JMS provider requirements lets JMS make a bigger impact on architecture than it could previously.

The arrival of web services onto the scene has given provided another power tool for developers wishing to expose pieces of the business model to other applications. As described in Chapter 8, web services interfaces are based on WSDL. WebSphere Studio Application Developer (WASD) provides simple tooling that will allow a session bean to easily be exposed as a web service.

Given this backdrop and perspective, a simple view of a business exposing itself from a web services perspective might look like this:

In fact, web services represent the "interface" that external businesses would interact with to do "business". We have a set of technology around WSDL, SOAP, and UDDI that let us represent web services interfaces, an envelope format so we can flow requests over standard protocols, and a way to find the "services" that are needed. Web services leverage XML to pass requests and responses and are capable of using HTTP or other protocols to transport requests. These facts place web services in a position to go beyond older RPC-based distributed systems technologies such as CORBA and DCOM.

The "conceptual" business model described so far and the attendant technologies that enable implementation are a good start on the road to scalable and robust application architecture. However, this is not the end of our story. Additional technologies and constructs can enable further refinement and bring additional value to the architecture and resultant systems. Merely using simple session beans to implement and capture the business processes and flows will become a tedious and complex development activity. It actually can become a costly method of development for solving complex business problems. Building new business processes by assembling and composing existing business processes is desirable and possible, but not easy given only the base capabilities of J2EE 1.3 and web services.

We therefore need to augment our existing view with some additional concepts, which begin to further detail the shape and form of our business model:

click to expand

This figure also shows that our business process model or our business processes are really formalizations or clarifications of what is at the session-bean layer. If we were to look at the patterns that exist in the logic of business systems, we would see logic that enables a flow concept or a series of steps that are performed to properly execute a business process. This is represented by the Flows in the diagram. Other patterns also would be observed in business system logic, including business rules, and a state machine pattern. We will dig into the flow patterns and business rules in much more detail later in this chapter and see what WebSphere Application Server Enterprise (WASE) has to enable the construction of these kinds of processes.

We have also added the idea of a static model to the diagram to more formally represent the entities in the business and the relationship between those entities.

We will dig into some of this a bit more later, but the basics should be clear. We have:

  • Interfaces to the business model in the form of web services and in the form of traditional clients such as servlets/JSP pages or J2EE clients. The web services are represented as WSDL documents and are the entry point for external consumers of the services provided.

  • Entities in the form of entity beans. These entities are stateful in nature, and the state is persisted to databases or other resource managers.

  • Processes in the form of session beans, designed to accurately model the actual business flow of the organization.

Before moving on, we must observe that there is also the idea of web services and services in general being leveraged as part of implementing the business model. The following diagram, a variation on the previous diagrams, demonstrates this concept:

This final picture leverages and builds upon the idea of a service-oriented architecture that was presented in Chapter 7. The diagram above represents using J2EE to build a business model in the middle tier, combined with a service-oriented architecture, which not only exposes business services, but also leverages business services in the formation of new business value. The act of leveraging business services to create new business services is sometimes referred to as service composition. The workflow technology that we will describe later in this chapter is meant to enable exactly this kind of composition.

Where to Next?

WAS version 5.0 provides just about every piece of technology that you need to build one of the previously described application architectures. The upcoming sections will further detail some of the advanced capabilities in WASE, which are focused around assisting in the creation of rich, reusable, and robust application architecture.




Professional IBM WebSphere 5. 0 Applicationa Server
Professional IBM WebSphere 5. 0 Applicationa Server
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 135

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net