Are You Recruiter/Hiring Manager?
Cloud-based Candidate Screening | Online Tests
PMP 1600 Questions
PMP 1600 Questions
1600 PMP mock questions 1400 CAPM mock questions 800 SCJP 6 mock questions 600 OCAJP 7 mock questions 590 OCPJP 7 mock questions 556 SCWCD 5 mock questions 500 OCEJWCD 6 mock questions pdfDownload (java,struts, hibernet etc)

Tutorial Home

Hibernate

  • Advantage of Hibernate over JDBC
  • Hibernate Setup with an web Application
  • First Hibernate Application
  • Hibernate mapping with Database TABLE
  • Hibernate Data Type-Java Data Type - SQL Data Type mapping
  • One to Many Relation in Hibernate
  • One to Many Relation in Hibernate bi-directional
  • Many to Many Relation in Hibernate
  • HQL: The Hibernate Query Language
  • Criteria Queries
  • Criteria Queries : Equal (eq), Not Equal(ne), Less than (le), greater than (gt),greater than or equal(ge) and Ordering the results
  • Criteria Queries: And OR conditions
  • Hibernate generator to generate id (primary key)
  • prevent concurrent update in Hibernate,slate object updatation in Hibernate,version checking in Hibernate

    Struts


  • Model View Controller (MVC)
  • Model View Controller (MVC)
  • Struts Flow-How Struts Works?
  • Struts Tutorial - Struts Setup- First Struts Action class setup
  • Message Resources
  • Validation Framework
  • Validation Framework-client side
  • ForwardAction
  • IncludeAction
  • DispatchAction
  • LookupDispatchAction
  • DynaActionForm
  • DynaActionForm
  • Struts Tutorial - Mutli-click prevention using struts tokens-Prevent Duplicate Submission
  • Logic Iterate Map and List

    JSP


  • JSP Tutorial
  • Introduction to JSP
  • JSP Comments
  • JSP Syntax
  • JSP Scripting Elements :Scriptlet, expression, declaration
  • JSP Directives
  • implicit objects in JSP
  • JSP Actions
  • Introduction to JSP
  • jsp:useBean
  • The jsp:setProperty Action
  • The jsp:getProperty Action
  • Introduction to JSP

    Spring


  • Spring Tutorial
  • Introduction to Spring
  • Benefits of Using Spring Framework
  • Inversion of Control in Spring
  • Introduction to BeanFactory
  • Dependency Injection in Spring
  • Collections Setter Injection
  • Bean Scopes in Spring
  • Spring IOC Setup Step by Step
  • Bean Lifecycle in Spring
  • ApplicationContext
  • MessageSources in Spring
  • Web Spring MVC framework
  • Developing Your First Spring Web Application
  • Developing Your Second Spring Web Application with Spring Form
  • Developing Your First Spring Web Application with Spring Validation Framework with Code Example
  • Spring integration with Hibernate
  • Given a scenario, design a J2EE service using the Business Delegate, Service Locator, and/or Proxy client-side design patterns and the Adapter, Command, Web Service Broker, and/or Façade server-side patterns.

    Business Delegate

    Problem:

    • You want to hide clients from the complexity of remote communication with business service components. Business components are exposed to clients leading to coupling and fine-grained access.

    Forces:

    • Clients need access to business services.

    • Complexity of remote objects. You want to avoid unnecessary invocation of remote services.

    • Clients and business components become tightly coupled. You want to minimize coupling between clients and the business services, thus hiding the underlying implementation details of the service, such as lookup and access.

    • Business services APIs may change. You want to hide the details of service creation, reconfiguration, and invocation retries from the clients.

    Solution:

    • Use a Business Delegate to encapsulate access to a business service. The Business Delegate hides the implementation details of the business service, such as lookup and access mechanisms. Use a Business Delegate to reduce coupling between presentation-tier clients and business services:

    Consequences:

    • Reduces coupling, increases maintainability.

    • Implements failure recovery: Retry or Synchronize.

    • Translates network (System) Exceptions to Business service Exceptions.

    • Exposes simpler, uniform Interface to the business tier.

    • Performance enhancing cache.

    • Hides complexities of remote services.

    Service Locator

    Problem:

    • Clients want to transparently locate business components and services in a uniform manner.

    Forces:

    • Vendor dependencies are exposed to the clients, we want to encapsulate vendor dependencies for registry implementations, and hide the dependency and complexity from the clients.

    • Complexity and duplication of lookup and creation. Clients want to centralize and reuse the implementation of lookup mechanisms.

    • Clients may need to reestablish connection to a previously accessed business object.

    • Clients want to avoid performance overhead related to initial context creation and service lookups.

    Solution:

    • Use a Service Locator to implement and encapsulate service and component lookup. A Service Locator hides the complexities of Initial Context creation, lookup, and object re-creation:

    Consequences:

    • Abstracts complexity of lookups.

    • Uniform lookup for all clients.

    • Improves network performance.

    • Improves client performance by caching.

    Proxy

    Problem:

    • Provide a stand-in or placeholder to another object, in order to control access to it.

    Forces:

    • The desired object may be inaccessible (if it exists in a different address space).

    • The desired object may be expensive to instantiate and you want to delay its creation until absolutely necessary.

    • The desired object may need to be protected from unauthorized access.

    • You may need to perform special actions upon accessing the desired object.

    Solution:

    • Use a Proxy to provide a separate implementation of interface and working code for location transparency:

    Consequences:

    • Decouples interface and implementation by providing two objects.

    • Proxy handles all incoming requests to the object, it knows how to contact the object if it is remotely located.

    • Proxy passes along all authorized communication to the object (and prevents unauthorized communication).

    • If the Implementation class changes, the Proxy remains the same.

    • An example is the EJB's Remote Interface.

    Session Façade

    Problem:

    • Tight coupling between clients and business tier; fine-grained access.

    Forces:

    • You want to avoid giving clients direct access to business-tier components, to prevent tight coupling with the clients.

    • Numerous business objects are exposed over the network.

    • No uniform access to business tier. You want to centralize and aggregate all business logic that needs to be exposed to remote clients.

    • Clients are exposed to complex interactions and interdependencies of business objects. You want to hide the complex interactions and interdependencies between business components and services to improve manageability, centralize logic, increase flexibility, and improve ability to cope with changes.

    Solution:

    • Use a Session Façade to encapsulate business-tier components and expose a coarse-grained service to remote clients. Clients access a Session Façade instead of accessing business components directly. Use a Session Façade to encapsulate the complexity of interactions:

    Consequences:

    • Controller layer for business tier.

    • Uniform exposure of business components.

    • Reduces coupling between the tiers.

    • Provides a uniform coarse-grained access.

    • Centralizes business logic.

    • Centralizes security management.

    • Centralizes transaction control.

    • Exposes fewer remote interfaces to clients.

    • Improves performance, reduces fine-grained remote methods.

    Adapter (Wrapper)

    Problem:

    • Convert the interface of a class into another interface clients expect.

    Forces:

    • A potentially reusable class may not have the appropriate interface required by the particular application domain.

    Solution:

    • Adapter lets classes work together that could not otherwise because of incompatible interfaces. Use an Adapter pattern to adapt one interface to another:

    Consequences:

    • Adapter pattern maps the interface of one class onto another so that they can work together. These incompatible classes may come from different libraries or frameworks.

    • Adapter pattern can be used to expose existing component as Web Service.

    • Adapter pattern helps resolve integration issues.

    Command

    Problem:

    • There are a lot of similar methods, and the interface to implement that kind of object is becoming heavy.

    Forces:

    • Too many public methods for other objects to call. An interface that is unworkable and always changing. You feel that a method name must include prose describing the exact action, and this is preventing layering your code.

    Solution:

    • Encapsulate a request as a Command object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

    Consequences:

    • Command pattern is an example of pluggable behavior that enforce client access to Web Services.

    • The Command pattern is commonly used for gathering requests from client objects and packaging them into a single object for processing.

    • The Command pattern allows for having well defined command interfaces that are implemented by the object that provides the processing for the client requests packaged as commands.

    • Command design pattern provides a convenient way to store and execute an "Undo" function.

    • Command decouples the object that invokes the operation from the one that knows how to perform it.

    • Commands can be manipulated and extended like any other object.

    • Commands can be made into a composite command.

    • Commands can be stored. Since a command encapsulates all the data for a given request, it can be created and initialized at one point and applied at another.

    Web Service Broker

    Problem:

    • You want to provide access to one or more services using XML and web protocols.

    Forces:

    • You want to reuse and expose existing services to clients.

    • You want to monitor and potentially limit the usage of exposed services, based on your business requirements and system resource usage.

    • Your services must be exposed using open standards to enable integration of heterogeneous applications.

    • You want to bridge the gap between business requirements and existing service capabilities.

    Solution:

    • Use a Web Service Broker to expose and broker one or more services in your application to external clients as a Web Service using XML and standard web protocols:

    Consequences:

    • Introduces a layer between client and service.

    • Existing remote Session Façades need be refactored to support local access.

    • Network performance may be impacted due to web protocols.

    • Coordinates interactions among one or more services, aggregates responses and may demarcate and compensate transactions.

    The information you are posting should be related to java and ORACLE technology. Not political.