Benefits of IOC
-
Minimises code – no need to worry about creation
-
Testable
-
Loose coupling – Factory pattern – more
intrusive owing to explicitly requesting for compoenents
-
Eager instantiation and lazy loading
Dependency Injections vs JNDI
-
String based name
-
Lookup code is verbose
-
Retrieved objects are not checked at
compile-time
Describe Spring framework?
Difference between Bean factory and Application Context?
Core Container provides the essential basic functionality.
The basic package in the spring framework is the org.springframework.beans
package. The Spring framework uses JavaBeans and there are two ways in which
clients can use the functionality of Spring framework -- BeanFactory and
ApplicationContext. BeanFactory applies the IOC pattern and separates an
application’s configuration and dependency specification from the actual
application code.
Spring Application Context is a configuration file that
provides context information to Spring framework. The ApplicationContext builds
on top of the BeanFactory and inherits all the basic features of Spring
framework. In addition to basic features, ApplicationContext provides
additional features like event management, internalization support, resource
management, JNDI, EJB, email, and scheduling functionality.
BeanFactory is useful in low memory situations, which does
not have the excess baggage an ApplicationContext has. ApplicationContext
assist the user to use Spring in a framework oriented way while the BeanFactory
offers a programmatic approach.
RMI vs JMS
Are messaging applications slow? While there is some overhead
in all messaging systems, but this does not
mean that the applications
that are using messaging are necessarily slow. Messaging systems can achieve a
throughput of 100 messages
per second depending on the installation, messaging modes (synchronous versus
asynchronous, persistent
versus non-persistent), and acknowledgment options such as auto mode, duplicates
okay mode, and client mode etc. The asynchronous mode
can significantly boost performance by multi-tasking.
For example: In an Internet based shopping cart application, while a customer is
adding items to his/her shopping
cart, your application can
trigger an inventory checking component, and a customer data retrieval
component to
execute concurrently.
Are messaging applications reliable? This is basically a
trade-off between performance and reliability. If
reliability is more
important then the:
- Acknowledgment
option should be set to automode where once only delivery is
guaranteed
- Message
delivery mode should be set to persistent
where the
MOM writes the messages to a secure
storage like a database or a
file system to insure that the message is not lost in transit due to a system
failure.
Exception
Handling?
ACEGI
Security Framework –
- Authentication
- authorization ((J2EE declarative & programmatic)
- Data Integrity
- Confidentiality and privacy
- Non-repudiation and auditing
Java concepts:
1)
When would we use Vector/hashtable vs
ArrayList/HashMap?
2)
Can you tell me something about Garbage
collection in Java.. When does it occur, how does it perform it?
3)
Describe any memory leak you have encountered
and how to go about detecting and minimizing them? Weak references
4) What is a singleton pattern? How do you code it in Java?
A
singleton is a class that can be instantiated only
one time in a JVM per class loader. Repeated calls always
return
the same instance. Ensures that a class has only one instance, and provide a global point of access. It
can
be an issue if singleton class gets loaded by multiple class loaders.
public
class OnlyOne {
private static OnlyOne one = new OnlyOne();
private OnlyOne(){… } //private constructor. This class cannot be instantiated from outside.
public static OnlyOne getInstance() {
return
one;
}
}
To use it:
//No matter how many times
you call, you get the same instance of the object.
1)
OnlyOne myOne = OnlyOne.getInstance();
Program:
Write a JAVA function that deletes chars from a String. Any
character in remove must be deleted from str. Justify any design decisions
& discuss the time and space efficiency of the solution?
Good architecture?
Trial center must meet these above goals with a well
designed architecture. Specifically, the
Trial Center architecture must be designed to meet the following goals and
objectives.
- Performance – Trial Center must provide speedy response times
and efficient navigation.
- Scalability – Must provide the ability to scale from low to
high (thousands) of users.
- Maintainability – Trial Center must be easy to support and
maintain. The design must
accommodate changes to the slicing/dicing of operational metrics without
requiring changes to the source system publishers (to the degree possible).
- Availability – Since Trial Center will be a single point of
entry for all studies, the product and metrics it displays must support
99.9% uptime.
- Near Real Time – Changes to operational metrics should be
reflected in Trial Center within 3 – 5 seconds of being committed in a
source system.
- Reliability – The operational data presented must be
consistent with the data located in original systems.
- Aggregation – Trial Center establishes a platform for
aggregating operational metrics across all the systems involved in a
study.
Trial Center will serve as a data aggregator across
systems. This data will grow in size as
more studies come online. The system
must be designed to support strategies to provide efficient indexing of data
for filtering and aggregation purposes. When appropriate, metric totals may
need to be persisted and maintained in order to reduce the number of
computation requests to the database.
The system must also take advantage of a caching strategy to improve
performance and reduce the general number of database requests to the Trial
Center repository.
Trial Center’s application server must be able to scale
horizontally. Trial center must be able
to be supported in a web farm environment.
In order to support this, trial center must not hold state full
information in one app server. Any data
state must either be stored in the central repository or be distributed over an
in-memory distributed cache server. This
will allow the system to be load balanced as the number of users requests grow.
Trial Center will be designed in a very modular manner. Trial Center will adhere to a separation of
concerns approach to modular design and approach a more interface based
development philosophy. Trial center
will be tiered, whereby each tier will be responsible for specific
functionality. Dependency Injection will
be used to decouple the tiers. This will
ensure a clean separation between the business layers.
Additionally, the web framework will be built using MVC
architecture. This will create a clean
separation between HTML design and business logic.
Trial Center will support a clustering deployment
option. Clustering is generally defined
as two or more web servers that closely cooperate with each other to ensure
that each server in the group presents the same data to the end user. High availability will be achieved through
the use of creating redundant servers that can be switched over when a failure
occurs on the main server.
Data that is presented using Trial Center will be sourced by
other systems. Other systems will push
data to Trial Center when the transaction occurs in the source systems. This will allow the consolidation of the data
to be applied in a timely manner. In
general, data from source system must push the data into Trial Center within
3-5 seconds.
Since data will be sourced from multiple systems, Trial
Center must show data that represents the current state. Counts in Trial Center must match the current
counts in the source system. In order to
accomplish this, the data must arrive in a timely manner and the messaging
transport must be reliable. No missed transactions can ever occur during
transport.
