The Enterprise Bean Component

Enterprise JavaBeans server-side components come in three fundamentally different types: entity, session, and message-driven beans. Both session and entity beans are RMI-based server-side components that are accessed using distributed object protocols. Message-driven beans process messages from non-RMI systems like Java Message Service, legacy systems, and web services. All EJB servers must at least support a JMS-based message driven bean, but they may also support other types of message-driven bean.

A good rule of thumb is that entity beans model business concepts that can be expressed as nouns. For example, an entity bean might represent a customer, a piece of equipment, an item in inventory, or even a place. In other words, entity beans model real-world objects; these objects are usually persistent records in some kind of database. Our hypothetical cruise line will need entity beans that represent cabins, customers, ships, etc.

Session beans are extensions of the client application that manage processes or tasks. A Ship bean provides methods for doing things directly to a ship, but doesn't say anything about the context under which those actions are taken. Booking passengers on the ship requires that we use a Ship bean, but it also requires a lot of things that have nothing to do with the ship itself: we'll need to know about passengers, ticket rates, schedules, and so on. A session bean is responsible for this kind of coordination. Session beans tend to manage particular kinds of activities, such as the act of making a reservation. They have a lot to do with the relationships between different entity beans. A TravelAgent session bean, for example, might make use of a Cruise, a Cabin, and a Customer—all entity beans—to make a reservation.

Similarly, message-driven beans coordinate tasks involving other session and entity beans. Message-driven beans and session beans differ primarily in how they are accessed. While a session bean provides a remote interface that defines which methods can be invoked, a message-driven bean subscribes to or listens for messages. It responds by processing the message and managing the actions that other beans take. For example, a ReservationProcessor message-driven bean would receive asynchronous messages—perhaps from a legacy reservation system—from which it would coordinate the interactions of the Cruise, Cabin, and Customer beans to make a reservation.

The activity that a session or message-driven bean represents is fundamentally transient: you start making a reservation, you do a bunch of work, and then it's finished. The session and message-driven beans do not represent things in the database. Obviously, session and message-driven beans have lots of side effects on the database; in the process of making a reservation, you might create a new Reservation by assigning a Customer to a particular Cabin on a particular Ship. All of these changes would be reflected in the database by actions on the respective entity beans. Session and message-driven beans like TravelAgent and ReservationProcessor, which are responsible for making a reservation on a cruise, can even access a database directly and perform reads, updates, and deletes to data. But there's no TravelAgent or ReservationProcessor record in the database—once the bean has made the reservation, it waits to process another.

What makes the distinction between the different types of beans difficult to understand is that it's extremely flexible. The relevant distinction for Enterprise JavaBeans is that an entity bean has persistent state; session and message-driven beans model interactions but do not have persistent state.

Tags: EJB, enterprise bean, component, java beans, entity, session, message-driven, RMI, EJB server, persistent state, interactions

Reducing the Size of .NET Applications

Executable files for the .NET Framework currently cannot be packed by binary file compressors such as UPX (http://upx.sourceforge.net/) because .NET uses customized sections in the Portable Executable (PE) file (which is used by all Windows executable files). The .NET Execution Engine expects Common Language Infrastructure (CLI) data to be in the proper sections of the PE file. However, CLI data is placed in the PE sections uncompressed by default.

This article presents a technique for reducing the size of .NET executables without using native code or otherwise modifying the PE format. Instead uses reflection, which is supported by the .NET Framework, and pack the applications at a higher level.

Reducing the size of applications has several benefits:

• The disk space required is smaller. While disk space is usually not a problem in desktop computers, it can be in portable devices that run .NET Framework.
• Smaller executables load faster because of fewer disk accesses. Even if you uncompress the data in memory, RAM access is very fast and compressed executables still load faster than the original uncompressed ones.
• Using compression combined with, say, in-memory encryption/decryption makes it harder to disassemble .NET applications. This helps protect intellectual property.

The technique does not affect the usual development of .NET applications. The application EXE file and DLL files are built and compiled as usual. The technique can be applied as an additional step after you build the release version. Because of the generality of the solution, it is possible to generalize the technique to work with generic EXE and DLL files written in any .NET front-end language. I have created a tool called .NETZ, which is based on this technique (source code and binaries are available at http://www.st.informatik .tu-darmstadt.de/static/staff/Cepa/tools/netz/index.html and from DDJ; see "Resource Center," page 5).

Read Reduce the size of .NET applications

Tags: executable files, .NET, file compressors, PE file, CLI, .NET framework

Write a Simple Web Service .NET

You can write a simple XML Web service in a few minutes using any text editor. The service you will create in this section, MathService, exposes methods for adding, subtracting, dividing, and multiplying two numbers. At the top of the page, the following directive identifies the file as a XML Web service in addition to specifying the language for the service (C#, in this case).

<%@ WebService Language="C#" Class="MathService" %>

In this same file, you define a class that encapsulates the functionality of your service. This class should be public, and can optionally inherit from the WebService base class. Each method that will be exposed from the service is flagged with a [WebMethod] attribute in front of it. Without this attribute, the method will not be exposed from the service. This is sometimes useful for hiding implementation details called by public Web Service methods, or in the case where the WebService class is also used in local applications (a local application can use any public class, but only WebMethod classes are remotely accessible as XML Web services).

Imports SystemImports System.Web.ServicesPublic Class MathService : Inherits WebService   <WebMethod()> Public Function Add(a As Integer, b As Integer) As Integer       Return(a + b)   End FunctionEnd Class

VB 

XML Web service files are saved under the .asmx file extension. Like .aspx files, these are automatically compiled by the ASP.NET runtime when a request to the service is made (subsequent requests are serviced by a cached precompiled type object). In the case of MathService, you have defined the WebService class in the .asmx file itself. Note that if an .asmx file is requested by a browser, the ASP.NET runtime returns a XML Web service Help page that describes the Web Service.

Precompiled XML Web services

If you have a precompiled class that you want to expose as a XML Web service (and this class exposes methods marked with the [WebMethod] attribute), you can create an .asmx file with only the following line.

<%@ WebService Class="MyWebApplication.MyWebService" %>

MyWebApplication.MyWebService defines the WebService class, and is contained in the \bin subdirectory of the ASP.NET application.

Consuming a XML Web service from a Client Application

To consume this service, you need to use the Web Services Description Language command-line tool (WSDL.exe) included in the SDK to create a proxy class that is similar to the class defined in the .asmx file. (It will contain only the WebMethod methods.) Then, you compile your code with this proxy class included.

WSDL.exe accepts a variety of command-line options, however to create a proxy only one option is required: the URI to the WSDL. In this example, we are passing a few extra options that specify the preferred language, namespace, and output location for the proxy. We are also compiling against a previously saved WSDL file instead of the URI to the service itself:

wsdl.exe /l:CS /n:MathService /out:MathService.cs MathService.wsdl

Once the proxy class exists, you can create objects based on it. Each method call made with the object then goes out to the URI of the XML Web service (usually as a SOAP request).

For more information click here

Tags: web services, .NET, deploy, xml, expose methods, c#, webservice, precompiled, proxy class, uri, soap request

Introduction to Database Normalization

Database normalization can essentially be defined as the practice of optimizing table structures. Optimization is accomplished as a result of a thorough investigation of the various pieces of data that will be stored within the database, in particular concentrating upon how this data is interrelated. An analysis of this data and its corresponding relationships is advantageous because it can result both in a substantial improvement in the speed in which the tables are queried, and in decreasing the chance that the database integrity could be compromised due to tedious maintenance procedures.

Database normalization provides table optimization through the investigation of entity relationships. But why is this necessary? In this section, I’ll elaborate a bit upon why normalization is necessary when creating commercial database applications.
Essentially, table optimization is accomplished through the elimination of all instances of data redundancy and unforeseen scaleability issues.

Redundancy

Data redundancy is exactly what you think it is; the repetition of data. One obvious drawback of data repetition is that it consumes more space and resources than is necessary. Consider the following table:

Table 1-1: Poorly defined table

student_id	class_name	time	location	professor_id
999-40-9876	Math 148	MWF 11:30	Rm. 432	prof145
999-43-0987	Physics 113	TR 1:30	Rm. 12	prof143
999-42-9842	Botany 42	F 12:45	Rm. 9	prof167
999-41-9832	Matj 148	MWF 11:30	Rm. 432	prof145

Basically this table is a mapping of various students to the classes found within their schedule. Seems logical enough, right? Actually, there are some serious issues with the choice to store data in this format. First of all, assuming that the only intention of this table is to create student-class mappings, then there really is no need to repeatedly store the class time and professor ID. Just think that if there are 30 students to a class, then the class information would be repeated 30 times over!

Moreover, redundancy introduces the possibility for error. You might have noticed the name of the class found in the final row in the table (Matj 148). Given the name of the class found in the first row, chances are that Matj 148 should actually be Math 148! While this error is easily identifiable when just four rows are present in the table, imagine finding this error within the rows representing the 60,000 enrolled students at my alma mater, The Ohio State University. Chances that you’ll find these errors are unlikely, at best. And the cost of even attempting to find them will always be high.

Unforeseen Scaleability Issues

Unforeseen scaleability issues generally arise due to lack of forethought pertaining to just how large a database might grow. Of course, as a database grows in size, initial design decisions will continue to play a greater role in the speed of and resources allocated to this database. For example, it is typically a very bad idea to limit the potential for expansion of the information that is to be held within the db, even if there are currently no plans to expand. For example, structurally limiting the database to allot space for only three classes per student could prove deadly if next year the school board decides to permit all students to schedule three classes. This also works in the opposite direction; What if the school board subsequently decides to only allow students to schedule two classes? Have you allowed for adequate flexibility in the design so as to easily adapt to these new policies?

The remedy to these problems is through the use of a process known as database normalization. A subject of continued research and debate over the years, several general rules have been formulated that layout the process one should follow in the quest to normalize a database.

Find more

Tags: database normalization, tables, structure, optimization, database, query, redundancy, mapping, key, normalize, design