PaaS enabling Java EE applications through service meta-data and policies - Java One SFO 2012


LOGO

PaaS enabling Java EE applications through service meta-data and policiesBhavanisankara SapaligaJagadish Ramu

Birds Of Feather



The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.


Program Agenda• Introduction & Terminology• Service meta-data• Service Allocation Policy• Service Provisioning Order• Service Co-location Policy• Service Elevation Policy• SLA Policy• Service Augmentation Policy• Q& A


Cloud Computing

• On-demand Self-Service• Broad network access• Resource Pooling• Rapid Elasticity• Measured Service

Essential Characteristics

(*) NIST Definition of Cloud Computing – 800-145 (Draft)


Cloud Computing

• Software as a Service (SaaS)• Platform as a Service (PaaS)

– Deploy customer-created applications– Using languages and tools supported by PaaS Provider– No control of underlying cloud infrastructure– Control over deployed applications, hosting env. Configurations

• Infrastructure as a Service (IaaS)

Service Models

(*) NIST Definition of Cloud Computing – 800-145 (Draft)


PaaS and Java EE

• Common programming model for enterprise developers• Runtime handles application’s infrastructure concerns• Declarative resource references• Scalable (scale-out) component models• Application deployment drives provisioning of services

required by the application• Using standards based application on a PaaS

Java EE design principles and capabilities


Roles in a PaaS scenario


PaaS Implications on Deployment

• Automatic Service Provisioning and Management– Service Orchestration

• Automatic Service Dependency discovery• Service Provisioning and Association

– Handle operational infrastructure concerns automatically• Network configuration, HA, Clustering, Load Balancing …

– Application and Service deployment versioning

Services Management


State of the proposals & work• Most of these meta-data are derived as part of our

investigation and prototype work• Conceptual at this stage, not all features/meta-data may

have implementation.• Part of the meta-data is based on existing/proposed

standards (eg: Java EE 6 & 7 annotations, Java EE standard descriptors)


Terminology• Service• ServiceType

– Java EE, RDBMS, HTTP Load Balancer etc.

• Services – scope and lifecycle– Provisioned Services

• Application scoped• Shared

– External (a priori ) services

• Metadata

– Descriptors, annotations for provisioning, policies, references


Service Scopes● Services are scoped at various levels

● Global services, available for all tenants

● Tenant scoped services, available for all deployments of a tenant

● Application scoped services, available only for an application


Service Scopes & Types


Service Metadata

• Provisioning meta-data or references can be specified along with the application (eg: services.xml)

• Vendor specific descriptors (eg: glassfish-resources.xml )

• Standard descriptors or annotations

● Java EE 6 & 7 - resource annotations

– DataSource, MailSession, JMSConnectionFactory, JMSDestination etc.,


Specification of Service Metadata

• Optional– When not specified (vanilla EE app archives)

• Orchestration Engine automatically handles discovery of service deps• Automatic wiring to default Service Templates

– Metadata may be specified when:• Finer grain control of application environment desired• Application-specific Service configuration


Metadata Usage


Specification of Service Metadata

• Service Definition– Metadata used to provision and configure a Service

• What : Service characteristics (functional and non-functional) → Template matching

• How : Explicit Template specification → Template wiring

• Service Reference– An application component’s dependency on a Service

• Explicit : User-specified through deployment descriptors• Implicit and Discovered: Information contained within the archive


Service Metadata specification

Sample Service Description

<service-description name="salary-service" init-type="lazy">  <characteristics> <characteristic name="service-type" value="Database"/> <characteristic name="product-vendor" value="Oracle"/> <characteristic name="product-name" value="OracleDB"/> <characteristic name="product-version" value="11g"/> <characteristic name="os-name" value="OEL"/> </characteristics> <configurations> <configuration name="database.init.sql" value="init.salary-service.sql"/> <configuration name="database.name" value="salary_database"/> </configurations></service-description>

Service References● glassfish-resources.xml (Vendor specific descriptor):

<resources>

<jdbc-connection-pool res-type="javax.sql.DataSource" name="java:app/jdbc/test_pool">

<property name="service-name" value="global/mydb-service"/>

</jdbc-connection-pool>

<jdbc-resource pool-name="java:app/jdbc/test_pool" jndi-name="java:app/jdbc/MyRes"></jdbc-resource>

</resources>

● Services.xml



<service-reference name="lb-ref" service-name="global/my-shared-lb-service">


Service References● Using the @DataSourceDefinition annotation:

@DataSourceDefinition(

name="java:app/jdbc/DB1",

databaseName="sun-appserv-samples",

paas-enabled="true" | service-name=”global/mydb-service”

)

● Either paas-enabled or service-name can be specified.

● paas-enabled=”true” enables the dynamic binding of the @DSD to a Database service.

● A new Database service may get created or an existing service may be used (based on the allocation-policy)

● service-name=”global/mydb-service” binds this DSD to the mydb-service


Optional Service Dependencies

● An application can specify optional service dependencies.

● <service-ref name=”my-service-ref” service-type=”Caching” optional=”true”/>

● Optional, late binding of service depenencies● <service-ref name=”my-service-ref” service-name=”Caching”

optional=”true” late-binding=”true”/>

● Helps to notify when the optional service is made available later in the runtime so that the application or other dependent services can associate dynamically.


Service Naming conventions● JNDI style of name spaces:

● app/bookstore/BookstoreJavaService

● app/bookstore/BookstoreDBService

● tenant/tenant1/FooJavaEEService

● global/SharedOracleDBService

● Both shared and external services have “global/” namespace

● Using these naming conventions a service can be uniquely identified at any given scope


Sample Service Dependency Discovery


Service Allocation Policy

● Specified globally or per tenant level

● Default for all <service-reference> elements

● Can be over-ridden per :● service-type

● vendor-name

● product-name

● product-version

Service Allocation Policy

<tenant>

<policy>



<service-allocation-policy allocation-policy="shared"/>

<service-ref type="JavaEE" allocation-policy="dedicated"/>

<service-ref type="Database" allocation-policy="dedicated"/>

<service-ref type="Database" allocation-policy="shared" vendor-name="Oracle" product-name="Oracle-Database" product-version="11g"/>



<service-ref type="LoadBalancer" allocation-policy="shared"/>

</service-allocation-policy>

</policy>

</tenant>


Service Provisioning Order

● Default : As specified in the meta-data “services.xml”

● Specify order in the service description

● Derive any implicit service requirements unspecified in meta-data and formulate dependency graph

● Cyclic dependencies

– Use existing shared service

– Use “optional”, “lazy-binding” options

– Fail !

Service Provisioning Order<service-provisioning-order>



<provisioning-order mode ="meta-data"/>



<cyclic-dependency-resolution-policy mode="use-shared-service" >

</service-provisioning-order>


Service Co-location● Purpose:

● Multiple services or service nodes co-located in the same hardware (or virtual machine)

● Benefits:● Necessary for efficient use of hardware

● Helps the developer-mode deployments for unit testing multiple applications on the cloud


Service Co-location● Specification using services.xml:

<services>

<service-description name="myGlassFish">...</service-description>

<service-description name="myDatabase">...</service-description>

<service-description name="myLB">...</service-description>

<service-pool>myGlassFish,myDatabase,myLB</service-pool>

</services>


Service Co-location● Specification using policies : defines generic rule for co-locating

the services, in the absence of service-pool specified in services.xml

<policy>

<co-locate-services>

<service-ref type="JavaEE" vendor-name=”GlassFish”/>

<service-ref type="Database" vendor-name="JavaDB"/>

</co-locate-services>

</policy>


Service Elevation Policy

● Auto-detect and elevate an application-scoped-service to account scoped service

● When used as private cloud (on-premise), auto-detect and elevate an account-scoped-service to global-service

● Useful for optimized resource sharing with complete control

● Automatically downcast the scope when required so as to tie the service with application's state (enabled or disabled)

● Application disablement can also stop the running service to help reduce billing.


Service Elevation Policy<tenant>

<policy>

<service-elevation-policy enabled=”true”/>

<upcast-policy>

<event type=”app-deploy” applicable-scopes=”tenant, application”/>

<event-type=”app-redeploy” applicable-scopes=”tenant, application”/>

</upcast-policy>

<downcast-policy>

<event-type=”app-undeploy” applicable-scopes=”tenant, application”/>

<event-type=”app-redeploy” applicable-scopes=”tenant, application”/>

</downcast-policy>

<--elevation policy is disabled for LoadBalancer type -->

<service-type = “LoadBalancer” enabled=”false”/>

</service-elevation-policy>

</policy>

</tenant>


Service Level Agreement Policy● Service policies can be defined

<sla-policies>

<service-policy type="JavaEE">

<policy name=”max.concurrent.requests” exceeds=”10” action=”upgrade-account”/>

<policy name=”max.http.sessions” exceeds=”100” action=”upgrade-account”/>

</service-policy>

</sla-policies>

● These service policies will result in creating appropriate elasticity alerts and actions


Service Augmentation conventions● Upgrade the shared service to meet the application's

requirements

● For example, upgrade Java EE service from web-profile to full-profile

● Augmentation rules can be specified as policies● TBA


Resources

• Above the Clouds: A Berkeley View of Cloud Computing http://bit.ly/15MEL0

• The NIST Definition of Cloud Computing -- Special Publication 800-145(Draft) http://1.usa.gov/eZ8PSn

For more information

http://bit.ly/15MEL0

http://1.usa.gov/eZ8PSn


Q&A


Classic Duke Future Tech Duke

PaaS enabling Java EE applications through service meta-data and policies - Java One SFO 2012

Technology

Transcript of PaaS enabling Java EE applications through service meta-data and policies - Java One SFO 2012