We examine many aspects of the WebSphere programming model in this book. However, notwithstanding the breadth of coverage included in this book, the total WebSphere programming model is larger than we can hope to address between a single pair of covers. Fortunately, the majority of the WebSphere programming model is based on
Professional Java Server Programming J2EE 1.3 Edition , Wrox Press, ISBN: 1-86100-537-7
J2EE Design Patterns Applied , Wrox Press, ISBN: 1-86100-528-8
Expert One-on-One: J2EE Design and Development , Wrox Press, ISBN: 1-86100-784-1
To help put WebSphere in perspective, we provide an overview of the entire programming model in this chapter:
We begin with a discussion of the basic models of computing supported by the WebSphere programming model.
We then proceed with a discussion of the classic J2EE roles and some thoughts about additional roles that can contribute to the development and deployment of applications in your enterprise. This will include a discussion on how these roles play into the overall programming model process.
We follow with an overview and introduction to the additional programming facilities introduced by WebSphere that go beyond the J2EE standard, including the web services programming model.
This chapter will also outline the APIs included in the WebSphere programming model. It will provide some perspective on the value of the functions intrinsic to the WebSphere programming model – hopefully offering you some new ways of thinking about your business applications.
We will, in this discussion, provide some insight on which APIs are
WebSphere is a J2EE-compliant application server supporting the entire breadth of the J2EE specification. WebSphere version 5.0 is certified at the J2EE 1.3 level, and as such, J2EE is at the heart of the programming model. Given the platform portability
However, that only
WebSphere provides support for four basic models of e-business computing:
Integrated enterprise computing
The fundamental structures of application design enable distributed computing for different business and organizational scenarios. Most applications will eventually exploit a combination of these models to solve the needs of the environment in which they will be used. The WebSphere programming model covers the full span of each of these models.
If you are already familiar with the fundamentals of distributed computing, component programming, shared and reusable
Multi-tier distributed computing is what motivated the development of many of the core server technologies within WebSphere. The idea of component-based programming is to define reusable and shared business logic in a middle-tier of a three-tier distributed application:
The value of
Placing the presentation logic on the user's desktop has the benefit of enabling a rich interaction model with the end user. Placing the data logic in the traditional data center allows tight, centralized control over the data and information assets of the enterprise. Placing the business logic in a middle-tier allows for the exploitation of a variety of computing systems and better reuse and sharing of common computing facilities to reduce the cost of ownership that is commonly associated with expensive thick
The boundary between each tier represents a potential distribution point in the application, allowing each of the three parts to be hosted in different processes or on different computers. The J2EE programming model provides location transparency for the business logic, allowing you to write the same code irrespective of whether the business logic is hosted over the network or is in the same process. However, you shouldn't let this trick you into
Even if you don't distribute your application components across a network, you can still benefit from the boundary between the tiers. Every boundary that you are able to design into your application becomes an opportunity to 'plug-replace' other components. Thus, even nominal distribution of these
Through J2EE, WebSphere provides a
Secondly, the component architecture allows the client programming model to conform to well established rules, which implies that distributed components are shared components – that is, the same component can be used by many different applications
Finally, because the J2EE component model is designed around object-oriented principles, you are able to do a better job of modeling your business in the application design. This will help improve communication between you and your business end users – you can cast your application artifacts in terminology that they recognize, with behavior that is consistent with the conceptual model of the business they are trying to automate. We recommend that you exploit UML or some other standard modeling notation to define your basic business model design, and then use that model to generate the base J2EE artifacts in which you will implement that model. Rational Rose, for example, is one of several products that allow you to build a UML model, and then export that to a J2EE component implementation skeleton.
So, having a single, shared implementation and instantiation of business components in an environment where the developer doesn't have to deal with concurrency issues, not only
With the introduction of a component technology for business logic in a three-tiered distributed computing model, we immediately
From this was born the idea of multi-tier distributed computing, where the middle-tier of business logic could be
We should reiterate here that the multi-tiered distributed computing nature of component-based programming for business logic enables the integration of distribution points within your application design. It also defines a
In cases where you know the latency of distributed communication between two components cannot be tolerated in your application design, you can instrument your component with local interfaces that will defeat distribution, but still retain the benefits of component-based programming.
Many of the benefits of component-based programming come from the separation of application logic from concerns of information technology. In particular, the J2EE component model enables a
The component model allows the runtime to manage the component in the information system. This same principle of management applies to object identity, transaction and session management, security, versioning, clustering, workload balancing and failover, caching, and so on. In many cases, the runtime has a much better understanding of what is going on in the shared system than any one application can ever have, and thus can do a better job of managing the component and getting better performance and throughput in the information system. Since WebSphere is a commercially available product, you can acquire these benefits for much less than it would cost you to create the same capability on your own.
is, in some sense, a natural extension of the multi-tier distributed computing model whereby the presentation logic has been re-located in the middle-tier of the distributed computing topology, and
Web applications exploit the natural benefits of component-based programming to enable the construction of web presentation logic that can be hosted on a server platform, and to achieve richer styles of interaction than can be achieved with plain static content servers. The web application server was originally conceived to extend traditional web servers with dynamic content. However, in the course of developing these web application servers, we realized that the issues of serving presentation logic are
When creating WebSphere, IBM found significant synergies in the
An emerging trend in the industry is to further extend the benefits of component-based programming of presentation logic out into the network. This trend is motivated by the need to further reduce the effects of latency on end-user response time. This idea
Presentation components that manage simple catalog-browsing logic can be
The servlet and JSP programming model are discussed in more detail in Chapter 4. The role of edge serving in improving the performance of serving the presentation layer to the end-user interaction model is discussed further in Chapter 12.
Integrated enterprise computing is critical to retaining value in your past investments. Few new applications can be introduced into an established enterprise without some regard to how that will fit with existing applications and, by extension, the technology and platform assumptions on which those applications have been built. If you look into your enterprise you will find a variety of applications built on a variety of underlying technology assumptions. You may have applications built on SAP, CICS, Oracle, IMS, Windows, DB2, Tibco, PeopleSoft, Domino, MQSeries, and other proprietary technology bases. In many cases, you will be asked to integrate these applications into your application implementation.
In some cases you will be asked to create a new application that is intended to essentially replace an existing application – perhaps to exploit the productivity benefits of the J2EE-compliant, object-oriented, componentized or web-based capabilities provided by the WebSphere Application Server platform. It has become common for
In our experience, projects that propose massive re-engineering of existing information technologies to enable business process changes run a high risk of failure. This is due, in part, to the complexity of such projects as it is hard to keep the scope of such projects constrained to isolated portions of the overall business process; features and scope-creep push the project towards higher levels of complexity.
Another major risk factor in the case of such projects is the extent to which the re-engineering can
A more prudent approach to business process re-engineering is a more incremental approach – one that puts together an application framework representing the re-engineered process on the new technology foundation, but delegates the majority of its business function implementations to the business application legacy already being used in the enterprise. Over time, as the foundation and application framework mature and investment opportunity
Two things are key to enabling incremental business process re-engineering. The first is a good design for the new business application that will serve as a foundation for your business process objectives. This has to
The methodologies for creating a good framework design are a topic in itself. We won't go into that very deeply here. However, the principles of object-oriented design – encapsulation, type-inheritance, polymorphism, instantiation, and identity – are
As usual, the issues of cross-technology integration are complicated – in mission-critical environments, you must address concerns about data integrity, security, traceability, configuration, and a host of other administrative issues for deployment and management. However, to support the productivity requirements of your developers, these complexities should be hidden – as they are in the WebSphere programming model.
The key programming model elements provided by WebSphere for enterprise integration are
Messaging-based approaches to application integration are very effective and introduce a great deal of flexibility. The asynchronous nature of a message-oriented programming model allows the applications to be decoupled (or loosely coupled if they weren't
Series of applications designed in this manner can be strung together in various patterns to create a business system. The system can be re-wired in many different patterns to create different effects. No component ever has to know what other components it is wired to and so re-wiring can be accomplished without
In this sample enterprise information system (composed of several
The point is that all of these systems are loosely coupled – each responding to the messages they receive based on their own encoding and
Variations on message-oriented computing include: point-to-point asynchronous messaging,
Looking at the problem of application integration (or perhaps, more appropriately, lines-of-business integration) from the top, it is important to model your business process flows in a way that allows you to adapt those flows rapidly to new procedures and opportunities – to be able to model and then rapidly modify the order entry process to perform credit checks or to process partial orders, and other similar processes without having to re-write either your order entry or your inventory systems.
Business process management is discussed in greater depth in Chapter 10.
Services-oriented computing started out as the definition for the next level of coarse-grained functional composition – the idea being to aggregate interdependencies that you did not want to expose across a network boundary: the
SOA has a lot of affinity with business-to-business integration. More recently, SOA has re-emerged with a renewed focus on leveraging Internet technologies, and has been re-branded as
. The idea is to use XML as the basic message-encoding architecture, and HTTP as a communication transport, to provide a very low
We've come to realize that the fundamentals of services-oriented computing could be exploited to overcome similar barriers between lines-of-business within an organization as well. In fact, the exploitation of web services may, in the end, be more pervasive for intra-enterprise integration than for inter-enterprise integration. When combined with more classic approaches to enterprise integration and gateways, the principles of incremental business process re-engineering can be applied to integrate legacy systems into the services-oriented computing model.
Advances in the field of services-oriented computing are heavily focused on web services now –
We measure the coupling of distributed application components in at least three ways:
Temporal affinity is a measure of how the information system is affected by time constraints in the relationship between two components. If an application holds a lock on data for the duration of a request to another business service, there are expectations that the requested operation will complete in a certain amount of time – data locks and other similar semaphores tend to prevent other work from executing concurrently. Tightly-coupled systems tend to have a low tolerance for latency. On the other hand, loosely-coupled systems are designed to avoid temporal constraints – the application and the underlying runtime are able to execute correctly and without creating unreasonable
Organizational affinity is how changes in the system affect other parts of the system. A classic example of this is in the versioning of inter-dependent components. If the interface of a component changes, it cannot be used until the dependent components are changed to use that new interface. In tightly-coupled systems, the change has to be coordinated between the organization introducing the new interface and the organization responsible for using that interface. This often requires direct and detailed communication between the organizations. On the other hand, there is a high degree of tolerance for
Another dimension of organizational affinity is the degree to which the system has to be managed from a single set of administrative policies. Tightly-coupled systems tend to require a common set of administrative policies, most commonly handled with a centralized administration facility to ensure consistency of policy. The administration of loosely-coupled systems tends to be highly federated – allowing each party to apply its own administration policies and
Technology affinity addresses the degree to which both parties have to agree to a common technology base, to enable integration between them. Tightly-coupled systems have a higher dependence on a broad technology stack. Conversely, loosely-coupled systems make relatively few assumptions about the underlying technology needed to enable integration.
Our national road systems represent a very good example of a loosely-coupled system –
However, loose coupling also introduces a degree of inefficiency – sub-optimization, based on the
Messaging systems typically enable a degree of loose coupling. However, the majority of traditional messaging products typically introduce a higher degree of organizational affinity than web services (messages often carry a high-degree of structural rigidity), and a higher degree of technology affinity (requiring both parties to adopt the same proprietary software stack at both ends of the network – or suffer intermediate gateways). web services, on the other hand,
WebSphere takes the idea of web services to a new level – centering the elements of web services first on WSDL as a way of describing a business service. One of the things that you will encounter as you enter into the web services world is the realization that web services and J2EE are not competing technologies – in fact they are very
The industry tends to talk first, if not exclusively, about accessing web services with SOAP over HTTP. While SOAP/HTTP is critical to standard
Web Services Definition Language (WSDL) is an XML-based description of a web service containing interface (messages, port-types, and service-types) and binding (encoding and address) information – essentially how to use the web service and how to access it. WSDL is described in more detail in Chapter 8. We can then leverage this separation to maintain a corresponding separation of concerns between development and deployment. Programmers can use the port-type and message definitions to encode the use of a web service, whereas
One flaw in the web services specification is that the distinction between Document-oriented and RPC-oriented web services is captured in the binding – even though this distinction has implications on the programming model used by both the web services client programmer and the web services implementation programmer. We hope this issue will be resolved in future versions of the WSDL specification.
With this as a foundation, you can introduce all your business services as web services on a
. The services bus represents any of the business services that have been published as web services in your, or
The web services programming model is discussed further in Chapter 8.
The WebSphere Application Server supports the classic servlet- and EJB-component-based programming models defined by J2EE in support of both 'thick' clients and web-centered computing. In addition, it supports the following:
Control of multiple presentation device types – both traditional desktop browsers and other pervasive devices
web services for loosely
Message-oriented programming between application components
Business process management for scripting the flow of process activities implemented as J2EE components
Legacy integration through Java 2 Connectors and higher level adapters
We will discuss all of these models of computing through the rest of this book.
Given the models of e-business computing supported by WebSphere, we can identify a set of general application and component design patterns that can be mapped on to those e-business computing models. You should treat each of the general design patterns as building blocks – composing them to construct a complete business application based on an application design pattern. We provide a brief overview of the main component patterns here. All of these patterns are discussed in more detail later in this book. References to further discussions are included in each overview description.
It is worth considering how these basic component design patterns can be composed to form different application design patterns. We won't
Fast time to market
Often used to grow from a web presence to self-service
Separation of presentation and business logic.
This particular collection of characteristics has been classified as a
Stand-Alone Single Channel
User-to-Business Topologoy 1
) application pattern in the
Patterns for e-Business: A Strategy for Reuse
book by Jonathan Adams, Srinivas Koushik, Guru Vasudeva, and Dr. George Galambos ISBN 1-931182-02-7. A useful collection of online information
We recommend the use of this site in selecting a pattern for your application. This site does a good job of illustrating the rationale and
Classic three-tiered computing design puts the presentation logic on the user's desktop – based on the principle that rich user interaction requires locality of execution, and personal computers afford the processor bandwidth needed for the I/O and computational intensity of a Graphical User Interface (GUI).
WebSphere supports this model with the J2EE Client Container. You can write Java-based client applications, including those that exploit the J2SE AWT and Swing libraries for presentation logic, and then connect these clients to EJBs hosted on the WebSphere Application Server either through RMI/IIOP directly, or more loosely through web services client invocations.
There is very little treatment of this model in this book, although there is a brief discussion of it in Chapter 4, and the programming aspects of calling an EJB through RMI/IIOP or through a web service are no different from calling an EJB or web service from within a server-based component hosted on the application server. The deployment and launching processes are slightly different.
The web-client design takes advantage of the
WebSphere supports this model with the use of JSP pages and servlets. This model is discussed in depth in Chapter 4.
Model-view-controller (MVC) based designs are relevant to both thick client and web client-based application structures. The MVC pattern introduces a clean separation of concerns between the details of how information is laid out on a screen (the View) and the way business artifacts are laid out (the Model) and the control flow that is needed to operate on the model in response to input from the end user (the Controller).
The MVC pattern maps on to the J2EE programming model supported by WebSphere – views are implemented with JSP pages, models are implemented with EJBs, and controllers are implemented with servlets. Further, WebSphere supports the Apache Struts framework – a pre-engineered MVC framework based on JSP pages, servlets and EJBs.
We generally classify business logic as either representing procedures (for example, account-transfer, compute-shipping-charges, etc.) or as representing things you use in your business (for example, ledgers, accounts, customers, schedules, etc.). These map to session beans and entity beans, respectively. Generally, you will implement all of your high-level procedures (verbs) as
One of the significant benefits that comes from componentizing business logic –
Encapsulation of persistence and data logic within the entity bean can be done either with bean-managed persistence (BMP) where you're entirely responsible for managing the relationship of the bean's state to the underlying data system, or with container-managed persistence (CMP) where the container takes responsibility for managing that relationship. We recommend that you always use container-managed persistence whenever possible as the container can generally achieve a higher level of throughput and better resource utilization across the system given its knowledge of everything else that is going on.
Encapsulation of persistence and data logic is discussed further in Chapter 5.
Business procedures (or even entities) represented in your application design model may be actually implemented elsewhere in your information system – based on completely unrelated information technologies. Abstract components can be introduced to your application to represent this function implemented elsewhere. These abstract components are adapters – bridging between WebSphere and your non-WebSphere execution environments. In WebSphere, adapters based on the Java 2 Connector Architecture are implemented as session beans and/or web services. Further, interactions within the adapter to the external application may be implemented with micro-flows (a specialization of work flow) that can be used to compose multiple calls to the external program to form the function represented by the abstract component.
Conceptually, the use of adapters does not have to be limited to just encapsulating business procedure functions – adapters can also be used to encapsulate the state of business artifacts. This is generally achieved by implementing entity beans that make use of session beans that in turn are implemented as adapters to the external system.
Adapters and connectors are detailed in Chapter 7.
Request-response messaging can be used to form a remote-procedure-call (RPC)-like relationship between two components using messaging. Unlike RPC-based communication, the calls from a component to another component are not blocking. Instead, you issue a request message from one component to the other. Control is immediately handed back to your program, allowing you to perform some other work while you're waiting for the response to your request. In the meantime the second component will receive the request message, operate on it, and issue a response message back to your first component. The first component then needs to listen for response messages and correlate them to their corresponding request messages.
Another design pattern for message-oriented components is based on publishing and subscribing to notifications. With the pub-sub model you can create neural-network-like designs in your application. A component subscribes to a message topic that it works on. As messages of that type are generated by other components, the component receives the message and operates on it. It may produce other messages – perhaps of different types put on different topic queues. By interconnecting components of this
The web services design pattern represents an encapsulation of the business component that, having encapsulated the component with the formalisms defined by the web services standards, enables more loosely-coupled access to the business component. Web services do not define a component implementation model per se, but rather
The web services pattern is described in Chapter 8.
Workflow is a way of composing a set of individual business services and procedures into an overall business process. The workflow pattern is a powerful mechanism for codifying your business. It allows you to visualize your business processes, reason about their correctness and appropriateness to your markets, and quickly adjust your business processes as business conditions change. The design pattern involves capturing your business process in a workflow definition. The business process definition describes the flow of control and information between business activities. In turn, activities are defined in terms of web services – each activity in the flow is a call to a web service that implements that activity. In this sense, a workflow is a composition of business services used to perform that business process.
Workflows are discussed in more detail in Chapter 10.
Together, these models form relatively basic definitions of how to construct the components in your application. Your challenge, then, is to compose these components into an organization that fulfills the objectives for your application.