|
1)What
patterns are particularly useful in building networked applications?
I
suggest starting with
Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked
Objects (POSA2). POSA2 specifically brings together 17 interrelated patterns
addressing Service Access and Configuration, Event Handling,
Synchronization, and Concurrency.
The
patterns and many of the examples in POSA2 come primarily from the design and
implementation of the
ACE
framework.
2)Are
there any good Java-specific patterns books available?
The
Java-specific patterns books are:
As
far as the good part of the question.... Doug Lea's Concurrent
Programming book is probably the best of the bunch. However, its patterns
are specific to concurrent programming. Many people don't like the quality of
Mark Grand's two Patterns in Java books. [They are rated 3 and 2
stars at Amazon, respectively]. The first printing of the Cooper tutorial book
was riddled with errors. If you get that, be sure to get at least the second
printing. [Look on last line of page before TOC.] The SanFrancisco book is
definitely good, but I'm not sure how good if you aren't using SF.
3)What
are Collaboration Patterns?
Collaboration
Patterns are repeatable techniques used by teams of people to help them work
together (collaborate). Ellen Gottesdiener of
EBG Consulting has created these
patterns in order to help facilitate good teamwork. These patterns really have
nothing to do with object-oriented development or Java, besides the fact that
they can help with requirements gathering or CRC design sessions.
In
a nutshell, Collaboration Patterns are techniques to help make meetings
useful.
4)Is
it correct from a design point of view to make an object both an Observer and
Observable at the same time?
Yes,
and this can be the preferred pattern in some cases.
For
example, suppose you were writing a supply chain management system for a
retail chain. Each store object in your system generates item-sold events;
when the chain generates enough of these for a particular product, a buyer
object generates a purchase order for more of the product. However, the buyer
object has no particular interest in individual item sold events. Instead, the
buyer (Observer) registers to receive out-of-stock events from the warehouse
(Observable); the warehouse, as Observer, registers with the individual stores
(Observables) to receive item-sold events. Thus, the warehouse is both
Observer and Observable. (Please note that this is a synthetic example, and
probably not the way to organize a supply chain.)
Another
reason to use one or more central Observer-Observable object in between
ultimate Observers and Observables is to fully decouple the two. In some
cases, Observer and Observable may exist on different machines, and may rely
on the central Observer-Observable to hide this complication.
A
good source for more details is the Publisher-Subscriber section of Buschmann
et al., Pattern-Oriented Software Architecture: A System of
Patterns.
5)How
can I maintain a single instance of an object in an applet?
In
start(), instead of always creating a new object, return the existing one if it
exists or create a new one if it doesn't.
6)What
is the best way to generate a universally unique object ID? Do I need to use
an external resource like a file or database, or can I do it all in memory?
I
need to generate unique id's that will be used for node 'ID' attribute values
within XML documents. This id must be unique system-wide. The generator must be
available to a number of servlets that add various node structures to my XML
docs as a service. What is the best way to tackle this? The 'possible' ways I
can see:
-
Keep the maximum ID value in a flat-file where the service would read it
upon start-up and increment it. Upon shutdown or failure, it would write the
latest max id to the file.
-
Calculate the max id by searching the XML itself. This will be tougher since
XML requires an alpha-numeric value (not strictly numeric).
-
Use a database (MySQL) with a two-field table where one field is the
incremental counter.
I
just have this feeling that none of the above are the most efficient ways of
doing this.
Regards,
-Andy]
There
is an additional way to do that that doesn't rely on an external file (or
database) like the one you have presentred. If has been presented in the
EJB
Design Patterns book, written by Floyd Marinescu, and available in a pdf
format for free from the given link.
The
suggested solution is based on the UUID for EJB pattern, that comes out from
this question:
How
can universally unique primary keys can be generated in menory without
requiring a database or a singleton?
Without
enetring in the specifics (you can fully check out the pattern by reading the
appropriate chapter), the solution is to generate a 32 digit key, encoded in
hexadecimal composed as follows:
1:
Unique down to the millisecond. Digits 1-8 are are the hex encoded lower
32 bits of the System.currentTimeMillis() call.
2: Unique across a cluster. Digits 9-16 are the encoded
representation of the 32 bit integer of the underlying IP address.
3: Unique down to the object in a JVM. Digits 17-24 are the hex
representation of the call to System.identityHashCode(), which is guaranteed to return distinct
integers for distinct objects within a JVM.
4: Unique within an object within a millisecond. Finally digits
25-32 represent a random 32 bit integer generated on every method call using the
cryptographically strong java.security.SecureRandom class.
7)Is
there some kind of Design pattern which would make it possible to use the Same
code base in EJB and non EJB context?
A
good suggestion would be using Delegation
class PieceOfCode {
public Object myMethod() {}
}
class EJBImpl ... {
PieceOfCode poc = new PieceOfCode();
public Object myMethod() {
return poc.myMethod();
}
}
This
should not be a violation of EJB specs, since EJBs can use simple java classes
for their use. Think about Dependant Objects and so on.
8)What
is session facade?
Session
facade is one design pattern that is often used while developing enterprise
applications.
It is implemented as a higher level component (i.e.: Session EJB), and it
contains all the iteractions between low level components (i.e.: Entity EJB). It
then provides a single interface for the functionality of an application or part
of it, and it decouples lower level components simplifying the
design.
Think
of a bank situation, where you have someone that would like to transfer money
from one account to another.
In this type of scenario, the client has to check that the user is authorized,
get the status of the two accounts, check that there are enough money on the
first one, and then call the transfer. The entire transfer has to be done in a
single transaction otherwise is something goes south, the situation has to be
restored.
As
you can see, multiple server-side objects need to be accessed and possibly
modified. Multiple fine-grained invocations of Entity (or even Session) Beans
add the overhead of network calls, even multiple transaction. In other words,
the risk is to have a solution that has a high network overhead, high
coupling, poor reusability and mantainability.
The
best solution is then to wrap all the calls inside a Session Bean, so the
clients will have a single point to access (that is the session bean) that
will take care of handling all the rest.
Obviously
you need to be very careful when writing Session Facades, to avoid the abusing
of it (often called "God-Bean").
For
a detailed description of this pattern, check this page:
Core
J2EE Patterns - Session Facade
or get
Floyd
Marinescu's EJB Design Patterns, in PDF format.
9)How
is JDO different from VO ?
JDO
is a persistence technology that competes against entity beans in enterprise
application development. It allows you to create POJOs (plain old java objects)
and persist them to the database - letting JDO take care of the
storage.
Value
objects, on the other hand, represent an abstract design pattern used in
conjuction with entity beans, jdbc, and possibly even JDO to overcome commonly
found isolation and transactional problems in enterprise apps. Value objects
alone do not allow you to persist objects - they are simple data
holders used to transfer data from the database to the client and back to
the database.
Side
note: I know that many books out there still refer to these data holders as
value objects but the correct term is DTO: data transfer
objects. Value objects refer to objects that hold a value. A good example
of this java.lang.Integer object which holds an int.
10)How
can I implement the MVC design pattern using JSP?
The
MVC (Model View Controller) design pattern is a pattern/architecture that can
be used by GUI's. It seperates the application's data, user interface and
control logic into three separate entities. This ensures the system will be
more maintainable in the future as changes to one component will not have an
affect on the others.
The MVC pattern also conforms with the JSP Model 2 architecture.
The MVC pattern can be easily implemented in web applications using JSTL core,
JSP, Servlets and JavaBeans.
JSTL makes it easy for HTML designers to use dynamic data in their pages
without having to learn in depth java. The tags are in a recognizable HTML
like format meaning a smaller learning curve than taking on the JSP
specification after taking on the Java specification.
JSTL also makes it easy for web developers who are developing all aspects of
the application in helping you keep the content separate from the display by
keeping your JSP clean from any Java code. Since JSTL and its EL (expression
Language) are really only suited for accessing data, it forces you to use a
MVC pattern so long as you keep all JSP and Java syntax/code out of the JSP
pages.
A common scenario might look like this, a user sends a request to a server.
The request is handled by a Servlet (the controller) which will initialize any
JavaBeans (the model) required to fulfill the user's request. The Servlet (the
controller) will then forward the request, which contains the JavaBeans (the
model), to a JSP (the view) page which contains only HTML and JSTL syntax. The
JSTL will format the data into a human readable format before being sent back
to the user. Thus completing the full MVC process.
JSTL also has a tag library for XML processing, this could be used in an MVC
environment as you could replace the JavaBeans with an XML document to
describe your data, so long as the XML is still constructed in a controller
such as a Servlet before being passed to the JSP (the view).
JSTL also has a tag library for database access, using this in your JSP (the
view) pages would NOT comply to the MVC pattern as there will be no separation
between the model and the view.
java6 ejb3 jsf hibernate eclipse ajax groovy spring seam java struts webservice j2me guice java5 jca tapestry soa linux ria books
|
