Implicit Objects in JSP are objects that are automatically available in JSP. Implicit Objects are Java objects that the JSP Container provides to a developer to access them in their program using JavaBeans and Servlets. These objects are called implicit objects because they are automatically instantiated.
There are many implicit objects available. Some of them are:
request: The class or the interface name of the object request is http.httpservletrequest. The object request is of type Javax.servlet.http.httpservletrequest. This denotes the data included with the HTTP Request. The client first makes a request that is then passed to the server. The requested object is used to take the value from client’s web browser and pass it to the server. This is performed using HTTP request like headers, cookies and arguments.
response: This denotes the HTTP Response data. The result or the information from a request is denoted by this object. This is in contrast to the request object. The class or the interface name of the object response is http.HttpServletResponse. The object response is of type Javax.servlet.http. >httpservletresponse. Generally, the object response is used with cookies. The response object is also used with HTTP Headers.
Session: This denotes the data associated with a specific session of user. The class or the interface name of the object Session is http.HttpSession. The object Session is of type Javax.servlet.http.httpsession. The previous two objects, request and response, are used to pass information from web browser to server and from server to web browser respectively. The Session Object provides the connection or association between the client and the server. The main use of Session Objects is for maintaining states when there are multiple page requests.
Out: This denotes the Output stream in the context of page. The class or the interface name of the Out object is jsp.JspWriter. The Out object is written: Javax.servlet.jsp.JspWriter
PageContext: This is used to access page attributes and also to access all the namespaces associated with a JSP page. The class or the interface name of the object PageContext is jsp.pageContext. The object PageContext is written: Javax.servlet.jsp.pagecontext
Application: This is used to share the data with all application pages. The class or the interface name of the Application object is ServletContext. The Application object is written: Javax.servlet.http.ServletContext
Config: This is used to get information regarding the Servlet configuration, stored in the Config object. The class or the interface name of the Config object is ServletConfig. The object Config is written Javax.servlet.http.ServletConfig
Page: The Page object denotes the JSP page, used for calling any instance of a Page's servlet. The class or the interface name of the Page object is jsp.HttpJspPage. The Page object is written: Java.lang.Object
The most commonly used implicit objects are request, response and session objects
Showing posts with label Interview Questions. Show all posts
Showing posts with label Interview Questions. Show all posts
What are Event Handling in Web Service?
Wednesday, July 8, 2009
Event handlers can be associated with a scope or a process for concurrent processing of events. BPEL defines two types of events:
Message event—Implements a request-response or one-way operation invoked by a business partner
Alarm event—Implements timer-driven behavior
When a scope is active, then event handlers attached to the scope are enabled to receive concurrent messages or alarm events. They are disabled when the processing of the scope ends. Events can only be processed when the corresponding event handler is enabled. When the event handlers for a scope become disabled, running event handlers are allowed to complete. The scope is terminated when all event handlers have completed processing.
During the processing of message events, the event handler remains enabled. Therefore, it can concurrently process multiple events of the same type. In addition to flow activities, this is the second place in BPEL where concurrency is possible. Note that event handlers for a process can't create new process instances.
If an alarm event handler is specified with a duration, then this duration starts when the event handler for the scope is enabled.
Message event—Implements a request-response or one-way operation invoked by a business partner
Alarm event—Implements timer-driven behavior
When a scope is active, then event handlers attached to the scope are enabled to receive concurrent messages or alarm events. They are disabled when the processing of the scope ends. Events can only be processed when the corresponding event handler is enabled. When the event handlers for a scope become disabled, running event handlers are allowed to complete. The scope is terminated when all event handlers have completed processing.
During the processing of message events, the event handler remains enabled. Therefore, it can concurrently process multiple events of the same type. In addition to flow activities, this is the second place in BPEL where concurrency is possible. Note that event handlers for a process can't create new process instances.
If an alarm event handler is specified with a duration, then this duration starts when the event handler for the scope is enabled.
What is Compensation Handlers?
Compensation handlers that let you specify compensation logic to undo successfully completed activities in the case of a fault. The unit of compensation is, in its simplest form, one activity. It can also be a BPEL scope that forms a logical unit of work consisting of several activities and therefore needs to be compensated as such. A compensation handler specifically defines how to reverse the result of the particular unit it's associated with.
What are faults in a Web Service?
BPEL introduces fault handlers in order to let you deal with exceptional situations, such as the following:
A fault recognized as the result of a Web service invocation
A fault thrown explicitly by the process logic
A fault caused by a problem encountered by the runtime infrastructure
The BPEL runtime infrastructure recognizes a number of predefined exceptional situations within a running process instance. If such a situation occurs, a BPEL standard fault is raised. Examples for such standard faults are
mismatchedAssignmentFailure—Incompatible types in an assign activity
forcedTermination—Fault in an enclosing scope
correlationViolation—Message contents in receive, reply, invoke, or pick/onMessage don't match correlation data
uninitializedVariable—Attempt to access an uninitialized part of a message variable
invalidReply—Attempt to execute a reply for which no corresponding receive activity has been processed
Fault Handlers
In BPEL, fault handlers are the mechanism to explicitly catch these faults and respond to them in appropriate business logic. Fault handlers are associated with a scope activity or with the overall process.
When a fault is recognized, the scope or process first stops all its nested activities. Structured activities are terminated immediately. Some types of basic activities are also interrupted, including wait, receive, reply, and invoke. Other activities are considered short-lived and aren't interrupted.
A fault handler contains an activity that runs in case the corresponding fault occurs. For example, the fault handler may contain a reply activity that notifies a partner that normal processing of the logic can't be completed.
Syntactically, a fault handler is a catch or catchAll element. The catch element lets you specify the qualified name of a fault, a fault variable, or both. The fault variable can be omitted in cases where faults don't have additional data associated with them. The catchAll element doesn't have attributes.
Transition conditions on the links determine whether the validation result is OK or considered failed. In the latter case, a fault is thrown explicitly. The associated fault handler sends a fault reply message.
If a fault handler throws a fault itself, then this fault can be caught by the next higher enclosing scope. This applies to explicitly rethrown faults and to unexpected faults that occur during processing of the fault handler.
Not every scope has a fault handler specified for every possible type of fault. When a fault isn't caught by a fault handler, then a default fault handler applies. The default fault handler runs all available compensation handlers for immediately enclosed scopes in the reverse order of completion of the corresponding activities, and then rethrows the fault to the next enclosing scope.
The fault-handling concept in BPEL is similar to exception-handling in Java and other programming languages.
A fault recognized as the result of a Web service invocation
A fault thrown explicitly by the process logic
A fault caused by a problem encountered by the runtime infrastructure
The BPEL runtime infrastructure recognizes a number of predefined exceptional situations within a running process instance. If such a situation occurs, a BPEL standard fault is raised. Examples for such standard faults are
mismatchedAssignmentFailure—Incompatible types in an assign activity
forcedTermination—Fault in an enclosing scope
correlationViolation—Message contents in receive, reply, invoke, or pick/onMessage don't match correlation data
uninitializedVariable—Attempt to access an uninitialized part of a message variable
invalidReply—Attempt to execute a reply for which no corresponding receive activity has been processed
Fault Handlers
In BPEL, fault handlers are the mechanism to explicitly catch these faults and respond to them in appropriate business logic. Fault handlers are associated with a scope activity or with the overall process.
When a fault is recognized, the scope or process first stops all its nested activities. Structured activities are terminated immediately. Some types of basic activities are also interrupted, including wait, receive, reply, and invoke. Other activities are considered short-lived and aren't interrupted.
A fault handler contains an activity that runs in case the corresponding fault occurs. For example, the fault handler may contain a reply activity that notifies a partner that normal processing of the logic can't be completed.
Syntactically, a fault handler is a catch or catchAll element. The catch element lets you specify the qualified name of a fault, a fault variable, or both. The fault variable can be omitted in cases where faults don't have additional data associated with them. The catchAll element doesn't have attributes.
Transition conditions on the links determine whether the validation result is OK or considered failed. In the latter case, a fault is thrown explicitly. The associated fault handler sends a fault reply message.
If a fault handler throws a fault itself, then this fault can be caught by the next higher enclosing scope. This applies to explicitly rethrown faults and to unexpected faults that occur during processing of the fault handler.
Not every scope has a fault handler specified for every possible type of fault. When a fault isn't caught by a fault handler, then a default fault handler applies. The default fault handler runs all available compensation handlers for immediately enclosed scopes in the reverse order of completion of the corresponding activities, and then rethrows the fault to the next enclosing scope.
The fault-handling concept in BPEL is similar to exception-handling in Java and other programming languages.
What is Service-Oriented Architecture?
Thursday, July 2, 2009
Service Oriented Architecture or SOA for short is a new architecture for the development of loosely coupled distributed applications. In fact service-oriented architecture is collection of many services in the network. These services communicate with each other and the communications involves data exchange & even service coordination. Earlier SOA was based on the DCOM or Object Request Brokers (ORBs). Nowadays SOA is based on the Web Services.
Broadly SOA can be classified into two terms: Services and Connections.
Services:
A service is a function or some processing logic or business processing that is well-defined, self-contained, and does not depend on the context or state of other services. Example of Services are Loan Processing Services, which can be self-contained unit for process the Loan Applications. Other example may be Weather Services, which can be used to get the weather information. Any application on the network can use the service of the Weather Service to get the weather information.
Connections:
Connections means the link connecting these self-contained distributed services with each other, it enable client to Services communications. In case of Web services SOAP over HTTP is used to communicate the between services.
Technologies Used:
SOA is much different from point-to-point architectures. SOA comprise loosely coupled, highly interoperable application services. These services can be developed in different development technologies (such as Java, .NET, C++, PERL, PHP), the software components become very reusable i.e. the same C# (C Sharp) service may be used by a Java application and / or any other programming language. WSDL defines an standard, which encapsulates / hides the vendor / language specific implementation from the calling client / service.
Broadly SOA can be classified into two terms: Services and Connections.
Services:
A service is a function or some processing logic or business processing that is well-defined, self-contained, and does not depend on the context or state of other services. Example of Services are Loan Processing Services, which can be self-contained unit for process the Loan Applications. Other example may be Weather Services, which can be used to get the weather information. Any application on the network can use the service of the Weather Service to get the weather information.
Connections:
Connections means the link connecting these self-contained distributed services with each other, it enable client to Services communications. In case of Web services SOAP over HTTP is used to communicate the between services.
Technologies Used:
SOA is much different from point-to-point architectures. SOA comprise loosely coupled, highly interoperable application services. These services can be developed in different development technologies (such as Java, .NET, C++, PERL, PHP), the software components become very reusable i.e. the same C# (C Sharp) service may be used by a Java application and / or any other programming language. WSDL defines an standard, which encapsulates / hides the vendor / language specific implementation from the calling client / service.
What is UDDI?
UDDI (Universal Description, Discovery, and Integration) represents the discovery layer within the Web services protocol stack.
UDDI represents a technical specification for publishing and finding businesses and Web services.
At its core, UDDI consists of two parts.
First, UDDI is a technical specification for building a distributed directory of businesses and Web services. Data is stored within a specific XML format, and the UDDI specification includes API details for searching existing data and publishing new data.
Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification. The UDDI registry now enables anyone to search existing UDDI data. It also enables any company to register themselves and their services. The data captured within UDDI is divided into three main categories:
a)White Pages: This includes general information about a specific company. For example, business name, business description, and address.
b)Yellow Pages: This includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies.
c)Green Pages: This includes technical information about a Web service. Generally, this includes a pointer to an external specification, and an address for invoking the Web service.
Specification is available at uddi.org.
UDDI represents a technical specification for publishing and finding businesses and Web services.
At its core, UDDI consists of two parts.
First, UDDI is a technical specification for building a distributed directory of businesses and Web services. Data is stored within a specific XML format, and the UDDI specification includes API details for searching existing data and publishing new data.
Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification. The UDDI registry now enables anyone to search existing UDDI data. It also enables any company to register themselves and their services. The data captured within UDDI is divided into three main categories:
a)White Pages: This includes general information about a specific company. For example, business name, business description, and address.
b)Yellow Pages: This includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies.
c)Green Pages: This includes technical information about a Web service. Generally, this includes a pointer to an external specification, and an address for invoking the Web service.
Specification is available at uddi.org.
What is WSDL?
The Web Services Description Language (WSDL) currently represents the service description layer within the Web service protocol stack.
In a nutshell, WSDL is an XML grammar for specifying a public interface for a Web service. This public interface can include the following:
1)Information on all publicly available functions.
2)Data type information for all XML messages.
3)Binding information about the specific transport protocol to be used.
4)Address information for locating the specified service.
WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services.
In a nutshell, WSDL is an XML grammar for specifying a public interface for a Web service. This public interface can include the following:
1)Information on all publicly available functions.
2)Data type information for all XML messages.
3)Binding information about the specific transport protocol to be used.
4)Address information for locating the specified service.
WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services.
What is XML-RPC?
XML-RPC is a protocol that uses XML messages to perform Remote Procedure Calls. Requests are encoded in XML and sent via HTTP POST; XML responses are embedded in the body of the HTTP response. More succinctly, XML-RPC = HTTP + XML + Remote Procedure Calls.
What is the Web service protocol stack?
The Web service protocol stack is an evolving set of protocols used to define, discover, and implement Web services. The core protocol stack consists of four layers:
1)Service Transport: This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).
2)XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP.
3)Service Description: This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL.
4)Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI.
Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol stack includes a whole plethora of newer, evolving protocols. These include WSFL (Web Services Flow Language), SOAP-DSIG (SOAP Security Extensions: Digital Signature), and USML (UDDI Search Markup Language).
1)Service Transport: This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).
2)XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP.
3)Service Description: This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL.
4)Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI.
Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol stack includes a whole plethora of newer, evolving protocols. These include WSFL (Web Services Flow Language), SOAP-DSIG (SOAP Security Extensions: Digital Signature), and USML (UDDI Search Markup Language).
What is a Web Service
Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system. XML is used to encode all communications to a Web service.
For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language--Java can talk with Perl; Windows applications can talk with Unix applications.
Beyond this basic definition, a Web service may also have two additional (and desirable) properties:
First, a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method.
Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface.
The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration
For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language--Java can talk with Perl; Windows applications can talk with Unix applications.
Beyond this basic definition, a Web service may also have two additional (and desirable) properties:
First, a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method.
Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface.
The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration
Subscribe to:
Posts (Atom)
