Cloud Basic

Cloud 
A cloud refers to a distinct IT environment that is designed for the purpose of remotely provisioning scalable and measured IT resources. 

Cloud Service
A cloud service is any IT resource that is made remotely accessible via a cloud. Unlike other IT fields that fall under the service technology umbrella - such as service-oriented architecture - the term "service" within the context of cloud computing is especially broad. A cloud service can exist as a simple Web-based software program with a technical interface invoked via the use of a messaging protocol, or as a remote access point for administrative tools or larger environments and other IT resources.

Cloud service usage conditions are typically expressed in a service-level agreement (SLA) that is the human-readable part of a service contract between a cloud provider and cloud consumer that describes QoS features, behaviors, and limitations of a cloud-based service or other provisions.

An SLA provides details of various measurable characteristics related to IT outcomes, such as uptime, security characteristics, and other specific QoS features, including availability, reliability, and performance. Since the implementation of a service is hidden from the cloud consumer, an SLA becomes a critical specification.

Characterstics

Six specific characteristics are common to the majority of cloud environments:

1. On-Demand Usage
2. Ubiquitous Access
3. Multi-tenancy ( Resourcing Pooling)
4. Elasticity and Scalability
5. Measured Usage
6. Resiliency

Delivery Models

Here are the most common delivery models related to cloud computing:

• IaaS - Infrastructure as a Service (e.g., Oracle Cloud Infrastructure, Amazon Web Services)
• PaaS - Platform as a Service (e.g., Oracle Java Cloud Service, Google App Engine)
• SaaS - Software as a Service (e.g., Oracle Taleo, SalesForce.com)

Some of the more sophisticated offerings on the market derive directly from the aforementioned models:

• NaaS - Network as a Service (IaaS)
• iPaaS - Integration Platform as a Service (PaaS)
• DBaaS - Database as a Service (SaaS)

Deployment Models

These delivery models can be deployed and managed in a particular way, depending on access levels, permissions, resource availability, connectivity, security requirements and many other factors that will eventually shape the cloud offering’s deployment model of choice:

• Public Cloud - Multi-tenancy and resource pooling are maximized, because any cloud-based asset may be shared among a number of subscribers. Multiple organizations and particulars usually coexist in this model, though each tenant’s proprietary information can remain private and secure.
• Private Cloud – An organization owns, manages and provides a set of cloud-based resources, which will be ultimately used with diverse purposes by cloud consumers inside itself.
• Community Cloud – A group of organizations with a common nature and related goals can put together and manage cloud-based resources in a joint effort. Those resources can  be accessed and leveraged only by community members.
• Hybrid Cloud – A combination of two or more cloud offerings based on the  models described above. Regarding Oracle’s Cloud Adoption Strategy, this will be the case of most clients, which only enhances the need for a well-rounded Cloud Integration practice.

Cloud-to-cloud Integration

Source : http://whatiscloud.com/

Scopes in ADF

6 scopes are there for ADF.

1. Application scope
2. Session scope : There's no window uniqueness for session scope, all windows in the session share the same session scope instance. If you are concerned about multiple windows being able to access the same object (for example to ensure that managed beans do not conflict across windows), you should use a scope that is window-specific, such as page flow or view scope.
3. Page flow scope : EL expressions must explicitly include the scope to retrieve values. For example, to retrieve foo from the pageFlowScope scope, your expression would be #{pageFlowScope.foo}
4. Request scope : The object is available from the time an HTTP request is made until a response is sent back to the client.
5. Backing bean scope : Used for managed beans for page fragments and declarative components only,the object is available from the time an HTTP request is made until a response is sent back to the client. This scope is needed for fragments and declarative components because there may be more than one page fragment or declarative component on a page, and to prevent collisions, any values must be kept in separate scope instances. Therefore, any managed bean for a page fragment or declarative component must use backing bean scope. EL expressions must explicitly include the scope to retrieve values. For example, to retrieve foo from the backing bean scope, your expression would be #{backingBeanScope.foo}
6. View scope :

ADF Page LifeCycle Stages

Some of the properties like immediate, refresh, refreshCondition, deferred can be understood better only if we have knowledge of ADF Page Lifecycle.

The flow for ADF Page lifecycle is :
Restore --> jsfRestore --> initContext --> Prepare Model --> Apply Request Values --> Process Validations 
--> Update Model  Values--> Validate Model Updates --> jsfInvoke Application --> Metadata Commit
-->  before JSF Render Response --> Prepare Render --> after JSF Render Response

• If immediate = true : Validations, conversions and events associated with the component are processed during Apply Request Values phase. And, Process Validations, Update Model Values and Invoke Application phases are skipped.

Partial Submit v/s Auto Submit and Immediate

	Partial Submit	Auto Submit
Applicable for	Command components	Input Components

Role of immediate property :

Immediate = true : Validation will be skipped. If we have 2 tabs and each tab with an input text mandatory. We have set immediate = true on both. If the user does not provide the mandatory input field and moves to next tab, the error will not be coming