SCEA1.5 - Few Terms for exam

Session failover: ----- In a clustered environment, all requests for a particular session are directed to the same WebSphere Portal server instance in the cluster. In other words, after a user establishes a session (for example, by logging in), the user is served by the same WebSphere Portal server instance for the duration of the session. To verify which server is handling user requests for a session, you can view the global settings portlet in WebSphere Portal, which displays the node name of the WebSphere Portal server handling requests. If one of the WebSphere Portal servers in the cluster fails, the request is rerouted to another WebSphere Portal server in the cluster. If distributed sessions support is enabled (either by persistent sessions or memory-to-memory session replication), the new server can access session data from the database or another WebSphere Portal server instance

JMS delivery modes: ---The message delivery semantics cover a range of once-and-only-once to at-most-once delivery. In the once-and-only-once delivery mode, a message is guaranteed by the JMS provider to always arrive at the intended destination no matter what, and it's sent only once. Even in the pub/sub model in which multiple receivers may consume a copy of a broadcasted message, the rules still apply within the relative view of each consumer. Once-and-only-once delivery guarantee is accomplished by the JMS provider through the combination of a store-and-forward mechanism and a rigidly defined set of message acknowledgments
At-most-once delivery is a less stringent QoS setting on a message - the JMS provider is allowed to occasionally lose a message. A classic example I like to use is a stock feed application. If the broadcast of a particular ticker symbol doesn't reach its intended destination, another one will be along shortly.
Whether it's once-and-only-once or at-most-once, the key word is once. Regardless of the guaranteed-ness of the delivery mode, the JMS provider is responsible for ensuring that the messages are delivered in the exact order in which they are sent.

Polling ---- Server Polling - (Reverse Ajax)
Keeping the displayed information up-to-date was always difficult in web world. Before AJAX, one had to use JavaScript or META Refresh tag to get the page refreshed. This was quite annoying from the user experience point of view. However it was not as annoying as something that I experienced few days ago on one of the banks website (a bank in Australia). I was filling out the form and there were couple of select boxes on the page. I selected an option in the select box and moved onto next field just to realize that as I was typing, the page has been reloaded and all data entered past that select-box was gone and had to be re-typed again. Very, very annoying - and it's AJAX age already!
Server polling, in my humble opinion, is a great feature of AJAX. There is no need to refresh the whole page to obtain the required information. With AJAX, it is possible to:
update the forms with information as the user moves through the form (e.g. country - state - city)get the feedback about a long server-side or transport process (e.g. progress bar showing the percentage of the uploading file)fake the push of the updated data from the server (think stock prices, weather, traffic info)

SEI (Service end point implementation): ----
JAX-WS technology enables the implementation of Web services based on both the standard service endpoint interface and a new Provider interface. JAX-WS service endpoints are similar to the endpoint implementations in the Java API for XML-based RPC (JAX-RPC) specification. Unlike JAX-RPC, the requirement for a service endpoint interface (SEI) is optional for JAX-WS Web services. JAX-WS services that do not have an associated SEI are regarded as having an implicit SEI, whereas services that have an associated SEI are regarded as having an explicit SEI. The service endpoint interfaces required by JAX-WS are also more generic than the service endpoint interfaces required by JAX-RPC. With JAX-WS, the SEI is not required to extend the java.rmi.Remote interface as required by the JAX-RPC specification.
The JAX-WS programming model also leverages support for annotating Java classes with metadata to define a service endpoint implementation as a Web service and define how a client can access the Web service. JAX-WS supports annotations based on the Metadata Facility for the Java Programming Language (JSR 175) specification, the Web Services Metadata for the Java Platform (JSR 181) specification and annotations defined by the JAX-WS 2.0 (JSR 224) specification, which includes Java Architecture for XML Binding (JAXB) annotations. Using annotations, the service endpoint implementation can independently describe the Web service without requiring a WSDL file. Annotations can provide all of the WSDL information necessary to configure your service endpoint implementation or Web services client. You can specify annotations on the service endpoint interface used by the client and the server, or on the server-side service implementation class.
<http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/twbs_devjaxwsendpt.html>

EJB timer service: ---- Consider a reporting Application, that will send report in the form of mails, every Monday, or a Billing Service that sends credit or debit bills on the 1st of every month. These applications depend on time-based events. To be more precise, these applications should allow developers to schedule some business logic or process so that they can be executed at some regular intervals of time. This is the core concept behind EJB Timers.
EJB Timer Services are services that are provided by the container (or the Application Server) and developers can take advantage of the timer services by registering one or more enterprise beans for time-based notification.
Different Types of Timers:EJB basically supports two forms of Timer objects:
Single Action Timer Interval Timer

Streaming API for XML (StAX): --- a streaming Java-based,event-driven, pull-parsing API for reading and writing XML documents. StAX enables you tocreate bidrectional XML parsers that are fast, relatively easy to program, and have a lightmemory footprint.StAX is the latest API in the JAXP family, and provides an alternative to SAX,DOM, TrAX, andDOMfor developers looking to do high-performance stream filtering, processing, andmodification, particularly with low memory and limited extensibility requirements.To summarize, StAX provides a standard, bidirectional pull parser interface for streaming XML