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 set of requirements for a Web service, such as transactional needs, and security requirements, design and develop Web service applications that use servlet-based endpoints and EJB based endpoints.

    EJB based endpoint

    JSR 109 standardizes webservice in J2EE 1.4 using JAX-RPC. EJB 2.1 exposes Stateless Session bean as a web service endpoint using JAX-RPC interface and any webservice client can access the EJB webservice using SOAP 1.1 over HTTP. The developer can choose a web service endpoint interface for a stateless session bean whenever he wants to expose the functionality of the bean as a web service endpoint through WSDL. The clients for EJB Web Service endpoint may be Java clients and/or clients written in a programming language other than Java. A Java client that accesses the EJB Web Service has to use JAX-RPC client APIs. This is an example shows how can you expose your existing EJB applications as a webservice endpoint and how a pure Java client accesses the ejb webservice.

    We will use a simple Stateless Session bean TimeBean that displays the current time and locale information. For exposing the webservice endpoint you do not need to have home or remote interfaces for the EJBs, only the end-point interface that extends java.rmi.Remote and bean implementation class is required. Following the code for the service-endpoint for the EJB:

    
    package time; 
    
    import java.rmi.RemoteException;
    import java.rmi.Remote; 
    
    public interface TimeService extends Remote {
    	public String getDateTime (String name) throws RemoteException;
    }
    					
    					

    Then we have to define the end-point interface in ejb-jar.xml as follows:

    
    <session>
      <display-name>TimeServiceEJB</display-name>
      <ejb-name>TimeServiceEJB</ejb-name>
      <service-endpoint>time.TimeService</service-endpoint>
      <ejb-class>time.TimeServiceBean</ejb-class>
      <session-type>Stateless</session-type>
      ...
    </session>
    					
    					

    The WSDL file defines the web services e.g. the following MyTimeService.wsdl describes the Time ejb webservice:

    
    <?xml version="1.0" encoding="UTF-8"?> 
    
    <definitions name="MyTimeService" targetNamespace="urn:oracle-ws" xmlns:tns="urn:oracle-ws" 
                 xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
                 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
      <types/>
      
      <message name="TimeService_getDateTime">
        <part name="String_1" type="xsd:string"/>
       </message>
      
      <message name="TimeService_getDateTimeResponse">
        <part name="result" type="xsd:string"/>
      </message>
       
      <portType name="TimeService">
        <operation name="getDateTime" parameterOrder="String_1">
          <input message="tns:TimeService_getDateTime"/>
          <output message="tns:TimeService_getDateTimeResponse"/>
        </operation>
      </portType>
      
      <binding name="TimeServiceBinding" type="tns:TimeService">
        <operation name="getDateTime">
          <input>
            <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
                       use="encoded" namespace="urn:oracle-ws"/>
          </input>
          <output>
            <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
                       use="encoded" namespace="urn:oracle-ws"/>
          </output>
          <soap:operation soapAction=""/>
        </operation>
    
        <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>
      </binding>
       
      <service name="MyTimeService">
        <port name="TimeServicePort" binding="tns:TimeServiceBinding">
        <soap:address location="REPLACE_WITH_ACTUAL_URL"/></port> 
      </service>
    
    </definitions> 
    					
    					

    The mapping.xml file specifies the Java to WSDL mapping i.e. it contains the mapping between package names and XML namespaces, WSDL root types and Java artifacts, and the set of mappings for services. For example we will have the following contents for our mapping.xml:

    
    <package-mapping>
      <package-type>time</package-type>
      <namespaceURI>urn:oracle-ws</namespaceURI>
    </package-mapping>
    					
    					

    Deployment of webservices requires a deployment descriptor named webservices.xml in META-INF of the ejb-jar file. This descriptor specifies the set of web service descriptions that are to be deployed into the J2EE Application Server and the dependencies they have on container resources and services:

    
    <webservice-description>
      <webservice-description-name>TimeServiceEJB</webservice-description-name>
      <wsdl-file>META-INF/MyTimeService.wsdl</wsdl-file>
      <jaxrpc-mapping-file>META-INF/mapping.xml</jaxrpc-mapping-file>
      <port-component>
        <description>port component description</description>
        <port-component-name>TimeServicePort</port-component-name>
        <wsdl-port>
          <namespaceURI>urn:oracle-ws</namespaceURI>
          <localpart>TimeServicePort</localpart>
        </wsdl-port>
        <service-endpoint-interface>time.TimeService</service-endpoint-interface>
        <service-impl-bean>
          <ejb-link>TimeServiceEJB</ejb-link>
        </service-impl-bean>
      </port-component> 
    </webservice-description>
    					
    					

    Servlet based endpoint

    During the deployment of a service endpoint component on a servlet container based JAX-RPC runtime system, a service endpoint class is associated with a servlet. The associated servlet class is provided by the JAX-RPC runtime system (not by service endpoint developer) during the deployment. This association is configured in a manner specific to a JAX-RPC runtime system and its deployment tool. For example, a JAX-RPC deployment tool may configure a 1-1 association between a servlet class and service endpoint class. The associated servlet class corresponds to the configured transport binding for the service endpoint. For example, the servlet class javax.servlet.http.HttpServlet is used for the HTTP transport.

    The associated servlet typically takes the responsibility of handling transport specific processing of an RPC request and for initiating dispatch to the target service endpoint instance. Each Servlet.service(...) method maps to a single remote method invocation on the target service endpoint instance. The thread model (whether single threaded or concurrent) for the remote method invocation on the service endpoint instance depends on the runtime system specific servlet associated with the corresponding endpoint class. The Servlet specification provides facility for both concurrent and single threaded model (the latter through the SingleThreadModel interface) for the service(...) method on a servlet.

    When processing an incoming SOAP request for a one-way operation, the associated servlet is required to send back an HTTP response code of 200 or 202 as soon as it has identified the incoming request as being one-way and before it dispatches it to the target service endpoint instance.

    The term JAX-RPC Service Endpoint used within the JAX-RPC specification is somewhat confusing since both Service Implementation Beans require the use of a JAX-RPC run time. However, in this case it refers to the programming model defined within the JAX-RPC specification that is used to create Web services that run within the web container. The requirements are repeated here with clarification. Changes from the JAX-RPC defined programming model are required for running in a J2EE container-managed environment. A JAX-RPC Service Endpoint can be single or multi-threaded. The concurrency requirement is declared as part of the programming model. A JAX-RPC Service Endpoint must implement javax.servlet.SingleThreadModel if single threaded access is required by the component. A container must serialize method requests for a Service Implementation Bean that implements the SingleThreadModel interface. Note, the SingleThreadModel interface has been deprecated in the Servlet 2.4 specification. The Service Implementation Bean must follow the Service Developer requirements outlined in the JAX-RPC specification and are listed below except as noted:

    • The Service Implementation Bean must have a default public constructor.

    • The Service Implementation Bean may implement the Service Endpoint Interface as defined by the JAX-RPC Servlet model. The bean must implement all the method signatures of the SEI. In addition, a Service Implementation Bean may be implemented that does not implement the SEI. This additional requirement provides the same SEI implementation flexibility as provided by EJB service endpoints. The business methods of the bean must be public and must not be static. If the Service Implementation Bean does not implement the SEI, the business methods must not be final. The Service Implementation Bean may implement other methods in addition to those defined by the SEI, but only the SEI methods are exposed to the client.

    • A Service Implementation must be a stateless object. A Service Implementation Bean must not save client specific state across method calls either within the bean instance's data members or external to the instance. A container may use any bean instance to service a request.

    • The class must be public, must not be final and must not be abstract.

    • The class must not define the finalize() method.

    A Service Implementation Bean for the web container may implement the java.xml.rpc.server.ServiceLifeCycle interface:

    package javax.xml.rpc.server;
    
    public interface ServiceLifecycle {
    	void init(Object context) throws ServiceException;
    	void destroy();
    }
    					
    The ServiceLifecycle interface allows the web container to notify a Service Implementation Bean instance of impending changes in its state. The bean may use the notification to prepare its internal state for the transition. If the bean implements the ServiceLifecycle interface, the container is required to call the init(...) and destroy methods as described below.

    The container must call the init(...) method before it can start dispatching requests to the SEI methods of the bean. The init(...) method parameter value provided by the container is described by the JAX-RPC specification. The bean may use the container notification to ready its internal state for receiving requests.

    The container must notify the bean of its intent to remove the bean instance from the container's working set by calling the destroy() method. A container may not call the destroy() method while a request is being processed by the bean instance. The container may not dispatch additional requests to the SEI methods of the bean after the destroy() method is called.

    When should one implement Web services in J2EE 1.4 using stateless Session Bean as opposed to using Java class

    Use a stateless Session Bean to expose Web services if you:

    • Need to expose previously existing stateless Session Beans as Web services

    • Need declarative transaction management

    • Need the thread management provided by EJB Container

    • Need role based security

    Use Java classes to expose your Web services if you:

    • Need to expose previously existing Java classes as Web services

    • Want a light-weight system, and don't care much about transactional capabilities that an EJB container provides

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