Are You Recruiter/Hiring Manager

*Filter candidates using TestYourCandidate.com and save 80% time ( saving time for recruiters and interviewers)
*More than 50% candidates can be filtered on Candidate Screening online tests
*Inbuilt exams are available in library, created and tested by experts Try Today...

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.

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.