Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

Enterprise Development Strategies for Java, WebLogic Server, and the Oracle Fusion Middleware Stack

by Oracle Technology Network

5,067 views

From Oracle Technology Network Developer Day

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

File a copyright complaint

3 Embeds 39

http://www.slideshare.net	35
http://217.146.242.106:8181	3
http://translate.googleusercontent.com	1

Statistics

Likes: 5
Downloads: 510
Comments: 0
Embed Views: 39
Views on SlideShare: 5,028
Total Views: 5,067

Main point: protect ourselves legally This is our standard disclaimer--we will touch on some visionary things in this talk that should not be used for contractual purposes.
Why application grid? Development environments and frameworks Development with WebLogic Server Development with Coherence Development with TopLink Testing and tuning Impact of cloud computing Conclusion
Hello everyone and welcome to our session on application grid development. Application grid is a term we use to refer to an architecture and approach to foundation-level middleware, technologies such as application servers and transaction processing platforms. Within Oracle Fusion Middleware, these are probably best known to you with names such as WebLogic, Tuxedo, JRockit, and Coherence. You could think of these products as the “foundation of the foundation”. For enterprise developers, Application Grid is a solution to new requirements from the enterprise. The commercial web now tends to lead and inspire requirements with the enterprise: topics like performance concerns, the desire for real time feedback and analytics, how to make the most of unused memory resources, database growth and bottleneck, data service /web service bottlenecks, are just a few of the topics that are inspiring enterprises to formalizing their use of shared, in-memory data. Oracle has heard many different pain points from it’s customer base: -Successful SOA implementations can lead to overtaxed data services, single points of failure with data. -The growth of corporate databases can make for bottlenecks in performance, especially with read intensive applications. - Enterprises can use application grid technology to dynamically and automatically adjust the allocation of resources across needs, enabling much higher utilization out of hardware: since you are not provisioning each application for its own worst case, you get higher reliability through the multiplicity of resources, and higher performance through parallelization.
A powerful and compelling role for Application Grid is as a broker between the SOA / Portal application and one or more databases. Not only does this improve performance, it also significantly reduces load on legacy systems, relieving the potentially great expense of re-provisioning legacy data stores. Shared, in-memory caches also can dramatically improve certain types of Portal implementation: Caching for HTTP session state management -P13N CacheProvider SPI implementation to speed up applications making heavy usage of profile data -Sharing cached data between WSRP-federated portals When choosing an SOA strategy, corporations must rely on solutions that ensure data availability, reliability, performance, and scalability. They must also avoid “weak link” vulnerabilities that can sabotage SOA strategies. • How will data access services be affected by the increasing number of services and applications that depend on them? • How can I ensure that my services don’t fail when underlying services fail? • What happens when the database server reaches full capacity? And how can I ensure the availability of reliable data services even when the database becomes unavailable? A data grid infrastructure, built with clustered caching, addresses these concerns. It provides a framework for improved data access that can create a competitive edge, improve the financial performance of corporations, and sustain customer loyalty.
Now that we’ve described the scope of the types of problems application grid can solve for the enterprise, let’s discuss some of the things developers will likely require from an application grid development experience. These are some of the key requirements that Oracle believes developers need to effectively leverage the technology. Application Grid leverages modern tools and developer frameworks that developers are comfortable with. While Oracle offers supported tools like JDeveloper, Enterprise Pack for Eclipse, application grid technology (coherence in particular) is not tied to any particular IDE. Frameworks like Spring are integrated as first class-citizens in the runtime. Also, Java EE standards make it possible to develop on a different Java EE platform, moving to WebLogic later for testing, and production. The Coherence Incubator offers a number of application grid design patterns that architects and developers can use as a starting point. Leverage APIs that developers are comfortable with. JPA is a familiar API to many developers, and application grid technology eliminates typical limitations to JPA applications, especially in a cluster. Application Grid technology is only becoming more integrated up and down the stack – in the server, portal, persistence runtime, tools, etc – so you’ve never stuck in a dead end point solution with no room to grow. Also, with Oracle’s application grid solutions, you know that your application will run on infrastructure that addresses corporate architecture reviews, guidelines, compliance requirements, and can integrate to existing enterprise IT investments.
Why application grid? Development environments and frameworks Development with WebLogic Server Development with Coherence Development with TopLink Testing and tuning Impact of cloud computing Conclusion
So how does the technical evolution map to the platforms we’re used to, ME, SE, and EE. For the sake of brevity, not necessarily importance, let’s just look at SE and EE. The platforms, of course, exist for a reason: to provide a consistent, complete, hardware and OS-portable target for deploying Java applications. We can argue, and in fact as a community we’re always arguing, about what should and should not be in a given platform. But, one thing we can agree on is the fundamental goodness that such platforms have provided over time, even if they are showing some age at this time. We also use SE as a fundamental building block for EE, so for example, annotations introduced in SE5 were used extensively in EE5 to make EE developers’ lives easier. Java EE 5 was a big step forward with annotations, JAX-WS, JPA and Java EE 6 is an even bigger step forward with the Web profile (WLS can be run with -DserverType=WLX for a JSP/servlet engine like the Web profile already today ...). As you’ll see in the next slide, with the addition of (CDI) Context and Dependency Injection and widening the use of the POJO model will ensure that Java EE is no longer heavy weight.
Footnote: http://www.theserverside.com/tt/articles/article.tss?l=DependencyInjectioninJavaEE6 It is important to see where CDI fits with Java EE overall to properly grasp what it does and how it does it. CDI has no component model of its own but is really a set of services that are consumed by Java EE components such as managed beans , Servlets and EJBs. Managed beans are a key concept introduced in Java EE 6 to solve some of the limitations we talked about in the previous section with Java EE 5 style resource injection. A managed bean is just a bare Java object in a Java EE environment. Other than Java object semantics, it has a well-defined create/destroy life-cycle that you can get callbacks for via the @PostConstruct and @PreDestroy annotations. Managed beans can be explicitly denoted via the @ManagedBean annotation, but this is not always needed, especially with CDI. From a CDI perspective, this means that almost any Java object can be treated as managed beans and so can be full participants in dependency injection. In fact, managed beans are intended to become the fundamental building block for all Java EE components. Traditional JSF backing beans are now managed beans (likely annotated with @ManagedBean). All EJB session beans are now also redefined to be managed beans with additional services (thread-safety and transactions by default). Servlets are not yet redefined to be managed beans, but this is very likely to happen in the near future. In essence, all other Java EE APIs will add various services to the foundational managed bean concept, primarily via declarative annotations.
Frameworks and Dev Workbench Oracle JDeveloper provides an extremely productive development environment that covers the full development lifecycle and integrates features addressing the multitude of technologies used for building standard-based enterprise applications. Oracle JDeveloper integrates development features for Java/EE, SOA, BPEL, Web, Database, WebCenter Portal, Enterprise Service Bus, XML and Web services, Mobile Browser, and soon Native J2ME mobile into a single development tool. The various artifacts share the same project structure and development experience, simplifying both the learning curve and the development process of composite applications that leverage a multitude of technologies. Oracle JDeveloper focuses on increasing developers productivity by offering a visual and declarative approach to application design. A combination of visual editors, property inspectors, structure panes, and editing dialogs simplify and eliminate tedious coding. These declarative features provide a simpler way to define the components that construct an application. The application’s code is always accessible for direct manipulation as well. Changes can be made by either the declarative means or directly in the code and are reflected in both simultaneously. Oracle JDeveloper covers the full development lifecycle from initial design and analysis, through the coding and testing phases, all the way to deployment. Developers can design, generate, and visualize their code with UML, Java and database diagrams. An advanced coding environment and declarative and visual editors facilitate faster code development. Integrated testing, profiling, and code auditing features ensure the quality of the applications. Interfaces with versioning, build, and deployment tools enable packaging and deployment of the applications. Additionally, the new Oracle Team Productivity Center product adds an integrated hot-pluggable application lifecycle management (ALM) solution into JDeveloper. Developer can directly interact with a host of requirement-gathering and progress tracking solutions.
Oracle Enterprise Eclipse Pack is unique because it is the only development environment for a commercial Java EE and Middleware Platform that (I) does not require a proprietary version of Eclipse (installs as plug-in); and (ii) is based on the features that are forward compatible 100% with the base Eclipse Tool Set. These certified plug-ins for Eclipse will focus on developer productivity for Java, Java EE and Web services. As Oracle is able to achieve it’s vision for OEPE with short release cycles to match the underlying open source components, it will also continue to build out it’s AppXRay technology. The AppXRay technology tracks design time dependencies in your IDE, allowing as-you type, compiler level awareness of much more than java at design time. AppXRay manages framework artifacts for code completion, consistency checking with generated classes, configuration files or annotations, prebuilt error checking, and validation that reaches all the levels of your application. Simply right-clicking on any artifact allows a filterable visualization of all design time dependencies, enabling “what-if” impact analysis and immediate notification of changes made by team members upon your checkout. The result is superior awareness of all known artifacts and early detection of problems at development time, well before the costly deployment-debug cycle. The slide depicts most of the major technologies that AppXRay supports.
Oracle ADF is an end-to-end development framework, built on top of the Enterprise Java platform, and offering unparalleled productivity. The framework provides integrated infrastructure solutions for the various layers of the application including data access, business services development, a controller layer, rich Web, mobile and desktop interfaces, data binding, and security. Oracle JDeveloper offers features that simplify the development of ADF based application through its visual and declarative editors. Key new ADF capabilities introduced in recent releases include: - MS office clients (Excel front end to your Java business services using ADF Binding). - ADF Faces Rich Client Components – New set of over 130 Ajax enabled JSF components – using adaptive rending to render components in flash, ajax, html, or mobile ADF Controller – richer functionality that extends the JSF controller. - Team Productivity Center is an Application Lifecycle Management tool that enables software development teams to collaborate and work productively together when developing applications using JDeveloper, and an integration framework for 3 rd party ALM tools and repositories.
Oracle TopLink is a Java runtime that delivers a proven enterprise Java solution for all of your persistence needs based on high performance and scalability, developer productivity, and flexibility in architecture and design. Oracle TopLink’s core is the EclipseLink Project, which was selected as the reference implementation for JPA 2.0. Oracle TopLink adds the following capabilities to the open source EclipseLink technology: Inclusion of EclipseLink with Commercial Support TopLink Grid: JPA with Coherence Continued backwards compatibility Oracle WebLogic Server 10.3 Support Developer Tooling Support Oracle TopLink 11gR1 includes EclipseLink 1.2, which provides developers with a runtime for : JPA: Object-Relational JPA 2.0 preview Simplified configuration of advanced features using annotations and/or XML All leading RDMS with platform specific features, best ORM for the Oracle Database MOXy: Object-XML Binding JAXB and advanced native SDO: Service Data Objects EIS using JCA Resource Adapters DBWS: Database web services Supports multiple Containers WebLogic, OracleAS, WebSphere, GlassFish/SunAS, JBoss
Oracle WebLogic Server 11g is the leading implementation of Sun Microsystems' Java EE 5 platform. However, WebLogic Server's core value proposition is in areas not covered by the Java EE specification—enhanced management, ease-of-use, high availability, scalability, reliability, and performance. Indeed, WebLogic Server's value is not tied to any particular programming model, so it is therefore a natural fit with the new breed of non-Java EE Java programming models. The most exciting of these to emerge in recent years are models based on Inversion of Control (IoC)—of which the Spring Framework is the de facto implementation. Let’s look at how the Spring 2.5.x Framework, WebLogic Server, are integrated . As we shall see, the whole is greater than the sum of its parts. Simplified Configuration supporting Spring pre-configured beans Spring applications can use WLS services like Txmgr without explicitly configuring them in the spring configuration file WLS server resources that can be injected into Spring application without explicit declaration include datasource, connection pools, JMS destinations, WM, ThreadPool, and loadtime weaver WLS will detect these automatically without additional configuration work by the developer. Improved administration of Spring apps Support for the runtime mbeans for dynamic configuration statistics such as how many spring beans and their types, how many transactions executed by these beans etc. Console support for Spring components Monitoring the JavaEE and Spring application through WebLogic console Federated MBean for clustering support Expose both Spring configuration & runtime statistics info to Console Can’t change spring bean configuration
Main point: get everyone on the same page as to what an app server is and why it’s important So what is and application server, and why do we care? first and foremost, it implements a set of industry standard APIs, Java EE, and the quality of implementing these standards is make-or-break for performance and reliability, two linchpins of competitiveness. But if Java EE is an industry standard that anyone can implement, what is there to differentiate between different implementations of the spec? As long as they pass the compatibility test, aren’t all Java EE implementations the same? For enterprise developers, they are not. In addition to essentials like lightweight/rapid install/config, support from popular IDE tools, command line utilities, ANT and Maven tools, a server must be aligned with corporate architecture, compliance initiatives, and ideally be something that operations is already trained to use, or at least, will address their requirements for usage in the data center. So if we assume “the basics” are covered, what capabilities differentiate a Java EE implementation for developers? -Support of additional programming models beyond Java EE where appropriate option for tightly integrated IDE tools like Eclipse dynamic class redefinition and design time dependency analysis -- comprehensive, flexible ANT tasks integrated profiling, diagnostics at the JVM level - additional command line tools like wlst, a Jython scripting interface for configuration management to make dev-test-prod environment promotion easier Beyond what’s specified in the industry standards, application server vendors do different things in the way of clustering, integration, and management. These are directly related to scalability, flexibility, and how easy it is to manage not just a single application server instance, but you infrastructure in aggregate. These things drive our business goals of efficiency and simplicity.
WebLogic is easy to install and use, taking minutes to install and configure – and by disabling unnecessary containers, extremely fast boot times. Lightweight installers “ Core” WLS install option, add-ons (JDKs, etc) optional Reduce download and install time, installation footprint Advanced dynamic class redefinition: FastSwap Major Java class modification without requiring redeployment Accelerate develop/deploy/debug cycle Optional service startup Start WebApp container without starting EJB, JMS, JCA services Provide developer flexibility Deployment process/startup performance improvements EJB compilation performance improvements
Shorter cycles between changes to your code and seeing the result can save a lot of time when working on large applications. Oracle recognizes that you often need surgical precision in fixing bugs, but enterprise deployment units and codebases force time consuming re-deployment. One of the benefits of dynamic languages is they are interpreted, and have no compilation step – making iterative cycles quick. In a compiled, strongly typed language like Java – we can find similarities to those strengths of dynamic languages. Traditional Java EE development cycle: Edit > Build > Deploy > Test Developers must complete cycle for every code change Some IDEs remove the Build step through conditional compilation: (like AppXRay) Edit > Deploy > Test FastSwap’s goal is to eliminate the Deploy step too: Edit > Test Java 5 introduced dynamic class redefinition (DCR): Redefines classes in place Retains existing application state DCR limited to classes that retain their shape : Cannot add, remove, or change declared fields Cannot add, remove, or change declared method signatures This was time consuming and resulted in the loss of all non-serializable application state WebLogic FastSwap uses DCR, but removes its restrictions. WLS uses the ChangeAwareClassLoader to eliminate the Deploy step: No dropped classloaders No destroyed servlets, filters, etc No serialization or loss of application state Allows changes to class shape Result: Fast Turnaround Times This WebLogic feature in supported in both JDeveloper and OEPE.
WLST Provides a repeatable process for propagating configuration changes across environments, and quickly allows environments to be replicated and migrated. It’s a command-line scripting interface for managing and monitoring WebLogic Server instances, clusters, and domains, based on 100% pure Java implementation of Python. Not a hidden feature -- It's a “must use” which many customers are using today Stable supported API Enables flexibility for dev/test/prod domain creation Has a learning curve (Jython, WLST APIs) Repeatable automated process for domain creation Typically property file driven Enables avoidance of manual errors Single command to create a complex domain Pays-off even for scripting domains for development lifecycle of project (not just for test/prod)‏ Often integrated into 'continuous integration' processes
Main point: memory is becoming highly inexpensive; Java needs help making use of it. Memory is becoming highly inexpensive; Java needs help making use of it due to garbage collection, operating system limitations, and machine memory limits, and other issues. An alternative approach is needed. In memory caching is an ideal match with low cost commodity hardware, as a distributed cache can make optimal use of the memory across multiple machines, rather than each machine having unused capacity when not functioning at it’s maximum consumption. Put another way, rather than each machine needing to physically install a fixed amount of RAM for it’s own “high watermark” of memory consumption – the grid can pool memory from a group machines as needed. Coupled with intelligent routing, primary/secondary backup strategies for efficient use of network bandwidth, and many other reasons – in-memory storage can be as reliable as disk based persistent storage – just orders of magnitude faster. In fact, in memory caches work hand in hand with databases – just in ways that vastly reduce load.
Main point: define Coherence The Oracle Coherence In-Memory Data Grid is a data management system for application objects that are shared across multiple servers, require low response time, very high throughput, predictable scalability, continuous availability and information reliability. As a result of these capabilities, Oracle Coherence is ideally suited for use in computationally intensive, stateful middle-tier applications. Coherence is targeted to run in the application tier, and is often run in-process with the application itself, for example in an Application Server Cluster, making a Data Grid being reliable for use by transactional applications. A Data Grid is a system composed of multiple servers that work together to manage information and related operations - such as computations - in a distributed environment. An In-Memory Data Grid is a Data Grid that stores the information in memory to achieve very high performance, and uses redundancy—by keeping copies of that information synchronized across multiple servers—to ensure the resiliency of the system and the availability of the data in the event of server failure. By sharing application objects across multiple servers, coherence avoids the overhead typically involved in ORM (inject – relational mapping), achieving lower response times and high throughput
Let’s outline product capabilities, usage possibilities, and provides a brief overview of how one would go about implementing particular features from a developer / architect perspective. Clustered Data Management At the core of Coherence is the concept of clustered data management. This implies the following goals: A fully coherent, single system image (SSI) Scalability for both read and write access Fast, transparent failover and failback Linear scalability for storage and processing No Single-Points-of-Failure (SPOFs) Clusterwide locking and transactions Built on top of this foundation are the various services that Coherence provides, including database caching, HTTP session management, grid agent invocation and distributed queries. A single API for the logical layer, XML configuration for the physical layer Coherence supports many topologies for clustered data management. Each of these topologies has trade-offs in terms of performance and fault-tolerance. By using a single API, the choice of topology can be deferred until deployment if desired. This allows developers to work with a consistent logical view of Coherence, while providing flexibility during tuning or as application needs change. Data Storage Options While most customers use on-heap storage combined with dedicated cache servers, Coherence has several options for data storage: On-heap—The fastest option, though it can affect JVM garbage collection times. NIO RAM—No impact on garbage collection, though it does require serialization/deserialization. NIO Disk—Similar to NIO RAM, but using memory-mapped files. File-based—Uses a special disk-optimized storage system to optimize speed and minimize I/O.
Let’s continue reviewing the basics from a developer / architect perspective. Serialization Options Because serialization is often the most expensive part of clustered data management, Coherence provides the following options for serializing/deserializing data: java.io.Serializable – The simplest, but slowest option. com.tangosol.io.pof.PofSerializer – The Portable Object Format (also referred to as POF) is a language agnostic binary format. POF was designed to be incredibly efficient in both space and time and has become the recommended serialization option in Coherence. java.io.Externalizable – This requires developers to implement serialization manually, but can provide significant performance benefits. Compared to java.io.Serializable, this can cut serialized data size by a factor of two or more (especially helpful with Distributed caches, as they generally cache data in serialized form). Most importantly, CPU usage is dramatically reduced. com.tangosol.io.ExternalizableLite – This is very similar to java.io.Externalizable, but offers better performance and less memory usage by using a more efficient I/O stream implementation. com.tangosol.run.xml.XmlBean– A default implementation of ExternalizableLite Configurability and Extensibility Coherence's API provides access to all Coherence functionality. The most commonly used subset of this API is exposed through simple XML options to minimize effort for typical use cases. There is no penalty for mixing direct configuration through the API with the easier XML configuration. Coherence is designed to allow the replacement of its modules as needed. Namespace Hierarchy Coherence is organized as set of services. At the root is the "Cluster" service. A cluster is defined as a set of Coherence instances (one instance per JVM, with one or more JVMs on each physical machine). A cluster is defined by the combination of multicast address and port. A TTL (network packet time-to-live; that is, the number of network hops) setting can be used to restrict the cluster to a single machine, or the machines attached to a single switch. Under the cluster service are the various services that comprise the Coherence API. These include the various caching services (Replicated, Distributed, and so on) and the Invocation Service (for deploying agents to various nodes of the cluster). Each instance of a service is named, and there is typically a default service instance for each type. The cache services contain named caches (com.tangosol.net.NamedCache), which are analogous to database tables—that is, they typically contain a set of related objects. Caching Strategies ..are discussed in detail on the next slide.
Coherence provides several cache implementations: Local Cache—Local on-heap caching for non-clustered caching. Replicated Cache Service—Perfect for small, read-heavy caches. Partitioned Cache Service—True linear scalability for both read and write access. Data is automatically, dynamically and transparently partitioned across nodes. The distribution algorithm minimizes network traffic and avoids service pauses by incrementally shifting data. Near Cache—Provides the performance of local caching with the scalability of distributed caching. Several different near-cache strategies provide varying trade-offs between performance and synchronization guarantees. In-process caching provides the highest level of raw performance, since objects are managed within the local JVM. This benefit is most directly realized by the Local, Replicated, Optimistic and Near Cache implementations. Out-of-process (client/server) caching provides the option of using dedicated cache servers. This can be helpful when you want to partition workloads (to avoid stressing the application servers). This is accomplished by using the Partitioned cache implementation and simply disabling local storage on client nodes through a single command-line option or a one-line entry in the XML configuration. Tiered caching (using the Near Cache functionality) enables you to couple local caches on the application server with larger, partitioned caches on the cache servers, combining the raw performance of local caching with the scalability of partitioned caching. This is useful for both dedicated cache servers and co-located caching (cache partitions stored within the application server JVMs). Tech Details Appendix for Cache types/strategies Distributed Cache A distributed, or partitioned, cache is a clustered, fault-tolerant cache that has linear scalability. Data is partitioned among all the machines of the cluster. For fault-tolerance, partitioned caches can be configured to keep each piece of data on one or more unique machines within a cluster. Distributed caches are the most commonly used caches in Coherence. Replicated Cache A replicated cache is a clustered, fault tolerant cache where data is fully replicated to every member in the cluster. This cache offers the fastest read performance with linear performance scalability for reads but poor scalability for writes (as writes must be processed by every member in the cluster). Because data is replicated to all machines, adding servers does not increase aggregate cache capacity. Optimistic Cache An optimistic cache is a clustered cache implementation similar to the replicated cache implementation but without any concurrency control. This implementation offers higher write throughput than a replicated cache. It also allows an alternative underlying store for the cached data (for example, a MRU/MFU-based cache). However, if two cluster members are independently pruning or purging the underlying local stores, it is possible that a cluster member may have a different store content than that held by another cluster member. Near Cache A near cache is a hybrid cache; it typically fronts a distributed cache or a remote cache with a local cache. Near cache invalidates front cache entries, using configurable invalidation strategy, and provides excellent performance and synchronization. Near cache backed by a partitioned cache offers zero-millisecond local access for repeat data access, while enabling concurrency and ensuring coherency and fail-over, effectively combining the best attributes of replicated and partitioned caches. Local Cache A local cache is a cache that is local to (completely contained within) a particular cluster node. While it is not a clustered service, the Coherence local cache implementation is often used in combination with various clustered cache services. Remote Cache A remote cache describes any out of process cache accessed by a Coherence*Extend client. All cache requests are sent to a Coherence proxy where they are delegated to one of the other Coherence cache types (Repilcated, Optimistic, Partitioned).
Historically there's been a couple of ways to scale JPA applications. One of them is to add more nodes to your cluster. If you have a database tier and an application tier then you'd be adding machines to the application tier. The other thing you can do of course is tune your database by doing SQL analysis to improve query performance. But there are limits to the scalability achievable with these approaches. Clearly you can tune your database and at some point you're going to hit the point at which no more tuning is possible and your database is running as fast as it can. And continually adding nodes to a cluster will increase the load on your database. You can keep adding clients to your database and eventually it won't be able to handle any more—you'll reach a limit. By leveraging Oracle Coherence, TopLink Grid offers a third way to scale JPA applications that doesn't suffer from the limitations we just discussed. Limitations of current approaches: Disabling a Shared Cache often leads to DB bottleneck, memory shortage Memory footprint of application increases as each transaction has a copy of each required Entity Every transaction pays object construction cost for queried Entities. Cache coordination leads to clogged network, some risk of stale data, and is limited by the heap on each node Messaging latency means that nodes may have stale data for a short period. Cost of coordinating 1 simultaneous update per node is n 2 as all nodes must be informed— cost of communication and processing may eventually exceed value of caching Shared cache size limited by heap of each node
With the release of Oracle TopLink 11g (11.1.1.0.0) Oracle has introduced a solution which marries the standardization and simplicity of application development using the Java Persistence API (JPA) with the scalability and distributed processing power of Oracle’s Coherence Data Grid. Developers can leverage their investment in JPA and take advantage of the scalability of Coherence. Standard JPA applications interact directly with their primary data store, typically a relational database, but with TopLink Grid developers can choose to store some or all of their domain model in the Coherence data grid. TopLink Grid combines: the simplicity of application development using the Java standard Java Persistence API (JPA) with the scalability and distributed processing power of Oracle’s Coherence Data Grid. With TopLink Grid, developers have: -Simple configuration using annotations that align with standard JPA -The ability to choose which entities are stored in the grid versus those stored directly in the backing data store -Support for queries being executed against either the Grid or directly against the data store -Support for storing Entities with either eager or relationships into Coherence
There are three core TopLink Grid configurations: The first is "Grid Cache" where we use Coherence as a replacement for the shared cache implementation. We can configure this on an Entity by Entity basis—we can specify whether a particular Entity type is cached in Coherence or in the built-in shared cache. In this configuration, anything put into Coherence in one node is immediately available to every other node. The second configuration is "Grid Read". In this configuration all read queries for a particular Entity are redirected to Coherence. And the third configuration is "Grid Entity". In this configuration all read and write operations are redirected to Coherence instead of the database. Let's take a closer look at each of these configurations and their characteristics.
The diagram illustrates the how Coherence becomes a truly shared cache which spans the cluster. To each node the cache appears to be local but is in fact distributed across the cluster.
Now let's compare this with Hibernate's use of Coherence as a shared L2 cache. The first difference is that Hibernate's shared cache is a data cache. It caches data rows rather than objects and serializes these rows into Coherence. A Coherence cache hit in Hibernate incurs both deserialization and object construction costs every time and in every cluster member. For example, when an object is read from the database in Node One a data row object is constructed from the JDBC result row and an object is constructed. The data row object is serialized into Coherence. On Node Two, querying this same object by primary key would get a Coherence cache hit which would return the deserialized data row object. Hibernate will then pay the object build cost on Node Two to construct the object from the row. As you can see an object build cost will be paid on every node for every cache hit unlike in TopLink Grid where this cost is only paid on the initial read. The other significant difference is that Hibernate only uses Coherence as a cache. There is no way to leverage Coherence's ability to perform parallel queries in the grid to offload the database. Hibernate only uses Coherence in the most basic way whereas TopLink Grid is able to leverage the distributed compute power of the grid.
There are some limitations in the current TopLink Grid 11gR1 release. The first is in the JPQL can be translated. We're currently limited by the features that are provided by Coherence. So for example we can do simple selects as on the slide. This is easily translated to a filter. More complex queries, specifically queries involving joins, will not be transmitted into filters. So for example I have here "select e from Employee e where e.address.city = 'Bonn'" where both Employee and Address are Entities. In TopLink Grid with Coherence the Employee and Address entities are stored in different caches and we cannot currently process this query against Coherence. Instead we will follow the normal query processing route and translate the query into SQL and execute it against the database. We'll use the database to identify the results but we will then use Coherence to look for those entities in the cache to avoid having to pay object build costs. We also currently don't support projection or report queries so selecting data values of objects is not supported and such queries will also be directed to the database.
Testing is an integral part of enterprise software development. It is as important, if not the most important, as any other phase of the Software Development Lifecycle (SDLC). But testing an enterprise application is easier said than done. Since the code in a traditional Java EE application depends heavily on the application server, its functionality can be fully tested only when deployed inside a J2EE container. But in-container testing is too slow and too much of an obstacle to developer productivity especially if the project is relatively large and number of code artifacts (java source files) is high. While Oracle Application Testing Suite, AD4J and JRockit have offerings that can address certain types of testing (marked in red text)…. (UI testing, Regression Testing, Load Testing = Oracle functional testing, Oracle Load Testing) (Profiling / runtime instrumentation = AD4J / JRockit) … Spring (and open source in general) has had a major impact on the green stages of the lifecycle above. Spring can make test driven Java EE application development a reality by offering Java EE developers an easy and powerful framework to write and run both unit and integration tests outside the container. Its non-invasive configuration management, dependency injection to use mock objects, and consistent abstraction over hard-to-stub APIs makes unit testing outside the container easy. Its testing module uses Dependency Injection (DI) and Aspect Oriented Programming (AOP) techniques to create a foundation on which we can build our unit and integration tests. As you’ve seen previously in this presentation, spring is tightly integrated to the container, in order to make a transition from testing outside the container to with a container as painless as possible. Some Java EE services, like EJB3, that have evolved to a POJO model similar to Spring Beans that can be tested outside the container even without Spring. However, using some services JMS will still require that container.
This Enterprise Manager addon, Oracle Diagnostics Pack for Oracle Middleware, includes an application diagnostics for java (AD4J) feature that provides low overhead monitoring and diagnostic functionality to improve Java application availability and performance. It enables administrators to proactively monitor application performance and provides in-depth application details to diagnose problems. Most importantly, AD4J can perform all of these capabilities without any server restarts, no application instrumentation, and no additional performance overhead making it a perfect solution for monitoring and diagnosing production applications. This is a good solution to use when you are using a non-JRockit JVM, or when you are not sure which tier the issue is located in (database, middleware, application, etc). Oracle JRockit offers similar tools that, obviously, only work with JRockit, and can go a bit deeper into problems that live inside the JVM.
Oracle JRockit Mission Control provides operational information about Java applications with minimal overhead using a unique, nonintrusive monitoring technology and diagnostic tools for Oracle JRockit JVM environments. The solution offers greater insight into the JVM, higher developer productivity, and reduced end-to-end application latency. JRockit Mission Control, JRMC, is a multi functional tool that can help organizations in the entire lifecycle of software development. Specifically, the JRMC i s an extension to JRockit which provides profiling, monitoring, managing and diagnostics of your Java applications. - Exposed through JRockit Mission Control GUI (Eclipse Plug-in) JRockit Management Console JRockit Runtime Analyzer (JRA) Memory Leak Detector Latency Analysis Integrated in the JVM Near zero overhead Available on-demand, no instrumentation needed It can be used during development to help with tuning and optimization and find memory leaks. It can be used to optimize and/or understand garbage collection behavior, and troubleshoot concurrency / multi-threading issues in your applicaiton It can be used by operations to monitor system health and trigger alerts when the load is too high. It can be used by late line support to identify defects, both in running code and in recordings of the running system.
What is highly relevant about cloud computing for developers is the ability to potentially circumvent long approval / procurement cycles from their own internal IT department. This has tremendous value in a large enterprise where you might only have a temporary need to a particular OS/platform, say for QA or performance testing, and no time for long procurement cycles, or budget to get a new machine only for temporary use. Many enterprises are considering building their own cloud computing infrastructures – this “private cloud” approach is an alternative that delivers much of the benefits of public cloud without some of its disadvantages. The idea of a private cloud is that a central IT function within an enterprise sets up a cloud to be used by “customers” within that enterprise, customers such as individual departments. The enterprise as a whole of course does procure and set up physical infrastructure in this case. But the department customers have a cloud experience similar to interacting with public clouds: they login to a portal and deploy apps in a purely Web-based interaction. Application Grid provides is an enabler and solid foundation for Private cloud computing, as well as being enabled for cloud computing, with technologies like : JRockit Virtual Edition ( JRockit running directly on a Hypervisor) -JRockit running directly on a Hypervisor -Faster, More efficient use of HW resources -Simpler patching, better security -Easier configuration, self-tuning container -WebLogic Server running on JRockit Virtual Edition -Less complexity in provisioning, patching, deployment -Better performance with removal of operating system -Higher density on multi-core infrastructure http://www.istockphoto.com/file_closeup/?id=7224406&refnum=3021132&source=sxchu04
Main point: Appliance Builder substantially extends the self-service capability of OFM private cloud Here’s a new feature of OFM 11g that will be available in the next year. Fusion Middleware Appliance Builder takes an app or SOA service that Central IT has built [click], pulls up the code and all of the relevant environment such as application server cluster configuration [click], Web tier and database tier in a multi-tier architecture, data grid configuration, etc, and creates a reusable “appliance” out of it, which is then stored in Assembly Builder’s internal repository. When an application needs to be deployed onto a new runtime, the designer can pull up the assembly, create VM templates for each appliance and deploy those as running VM instances into an OVM farm . [click] note that this appliance can be created as many time by as many different departments as needed. [click] This is akin to the rapid provisioning that public cloud service provides like Amazon can provide with their self –service portals, except that groups VMs can be created at once to produce an assembly. Bill Dettleback notes: A designer introspects a physical environment, capturing all of the components (app servers, db, data grid, web server, etc) as “appliances”. They can also (in the future) download pre-built appliances from Oracle. The designer “wires” together the appliances indicating how they work (e.g. JDBC connections, load balancing, etc). These connections constitute an “assembly”. The assembly is stored in AB’s internal repository. When an application needs to be deployed onto a new runtime, the designer can pull up the assembly, create VM templates for each appliance and deploy those as running VM instances into an OVM farm. While running, if an appliance needs to scale out, then AB can deploy additional VM instances accordingly to handle the load. The same assembly can be used over and over again- producing a fully configured and tested runtime architecture.
Oracle believes this will be the most common developer scenario for cloud development: Remote debug and deploy, with the IDE installed locally. Application Servers, Database, etc are remote. Debug ports are configurable on both Enterprise Pack for Eclipse / JDeveloper, and since Amazon’s ecurity group (firewall) is configurable, you can run the traffic over whatever ports your network requires.
This is an alternative where everything is remote, and the developer is using VNC or MSFT Remote Desktop to control a remote machine. Everything is installed remotely. There are other scenarios (building everything locally and just deploying a finished WAR/EAR to a remote amazon server, for example) but these are the most common types.
Why application grid? Development environments and frameworks Development with WebLogic Server Development with Coherence Development with TopLink Testing and tuning Impact of cloud computing Conclusion
Main point: summarize presentation [Summarize entire presentation.]

5 Likes

sunnylzg 1 year ago
technoapz 1 year ago
Sylvain Charette, Software Designer at Mxi Technologies Tags weblogic java development strategy 2 years ago
shyamchin Tags weblogic eclipse 3 years ago
Eugene van der Voort at Ordina 3 years ago

Enterprise Development Strategies for Java, WebLogic Server, and the Oracle Fusion Middleware Stack Presentation Transcript

Enterprise Development Strategies for Java, WebLogic Server, and the Oracle Fusion Middleware Stack
- 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.
©2010 Oracle Corporation
Application Grid Agenda & Roadmap ©2010 Oracle Corporation ©2010 Oracle Corporation Testing, Tuning, Diagnostics Cloud – App Grid Deployment 1. Why App Grid? 2. Roadmap 3. Conclusion
©2010 Oracle Corporation Fault tolerance Replicate data in grid for fail-over Enterprise Requirements are Advancing Shared, in-memory data addresses broad range of use cases ©2010 Oracle Corporation Application Application Grid with Coherence Application Application Grid with Coherence Frequent access to shared data Cache data in grid to offload back end High-speed, data-intensive computing Hold data in-memory; parallelize tasks
SOA and Portals Need Application Grid Enterprise data brokers remove bottlenecks for UI and data services Application Servers Web Servers Ever Expanding Universe of Users Data Supply
- Oracle Coherence brokers data supply with data demand
- Scale out data grid in middle tier using commodity hardware
- Broker data supply and demand
Data Sources Java Objects ©2010 Oracle Corporation Data Demand
Application Grid Agenda & Roadmap ©2010 Oracle Corporation ©2010 Oracle Corporation Testing, Tuning, Diagnostics Cloud – App Grid Deployment 1. Why App Grid? 2. Roadmap 3. Conclusion
Java SE/EE Platform Evolution Java EE 6 More POJOs, Web Profile, EJBLite, Restful WS, Injection, … J2SE 1.4 NIO, JAXP, Crypto, SSL, Logging, … J2SE 5.0 Generics Annotations Autoboxing Concurrent … Development Approach (POJO) ©2010 Oracle Corporation 1998 2000 2002 2004 2006 2008 2010 J2EE 1.2 Servlet, EJB, JSP, JMS, Mail, … J2EE 1.3 JCA, JAAS, XML, CMP, … J2EE 1.4 WebSvcs, JMX, Deployment, … Java EE 5 JPA, EJB3, Annotations, Faces, … J2SE 1.3 HotSpot, JNDI, JPDA, Sound, … Java SE 6 Performance, Scripting, JAX-WS, JAXB, StAX, … JDK 7 Modularity, Coin, InvokeDynamic, NIO2, …
Trend to Lightweight, Testable Plain Java Objects
- Less configuration complexity
- Easier testability and alignment with OS tools
- Java EE 6.0 makes advances in this area
©2010 Oracle Corporation Development Approach (POJO) Managed Beans JPA 2 Context Dependency & Injection JSF2 EJB 3.1 JAX-RS JAX-WS Persistence Facelets JSR 330 Basic Component Presentation Dependency Injection Business Services REST SOAP
DBMS Modeling Java Java EE ESB BPM Rules Portal Mobile / Desktop Common IDE Framework Common Modeling Framework Common Business Catalog Common Metadata Manager Common App Lifecycle Management JDeveloper 11 g Unified Java / SOA IDE ©2010 Oracle Corporation Frameworks and Dev Workbench
AppXRay™ Presentation Component Data Access External Resources Java / Java EE Web Services WebLogic Server Spring, ORM, DB Oracle Enterprise Pack for Eclipse Open source skill leverage increases productivity ©2010 Oracle Corporation Frameworks and Dev Workbench Artifact JSP CSS JSF JSTL HTML Struts Web Services POJO Resource bundles XML schema Java Variable Spring DAO EJB 3 JPA Hibernate TopLink
Business Services Data Services Model Controller View Desktop Browser/ Mobile Devices MS Office Oracle ADF 11g – For Declarative/Visual Developers Standards-based productivity with choice ©2010 Oracle Corporation Frameworks and Dev Workbench Relational Data XML Data Legacy Data Relational Data XML Data Legacy Data JSF MS Office ADF Faces JSP Swing JSF / ADFc Struts Web Services Java EJB BAM BPEL ADF BC BI XML Portlet ADF Bindings (JSR 227) Metadata Services TopLink JCR JMX Packaged Apps
Eclipse Persistence Services Project (EclipseLink)‏ XML Data Legacy Systems Databases ©2010 Oracle Corporation The Persistence RI for Java EE 6: Frameworks and Dev Workbench DBWS SDO EIS MOXy JPA Java SE Java EE OSGi Spring ADF
- Simplified configuration supporting Spring pre-configured beans
- Spring console now displays runtime mbeans for dynamic statistics
- Oracle JDeveloper, Oracle Enterprise Pack for Eclipse support
- MedRec Sample App upgraded with Spring 2.5.3
- Spring DI upgraded to support Spring 2.5.3
WebLogic Cluster/Domain Managed WLS WLS Admin Server Managed WLS Managed WLS Managed WLS Simplified Configuration Distributed Monitoring Spring Framework support in the foundation Seamless Oracle WebLogic Server integration Frameworks and Dev Workbench Spring Apps WLS JEE WLS Console Spring Apps WLS JEE Spring Apps WLS JEE Spring Apps WLS JEE
Oracle WebLogic Server Converged infrastructure for the Oracle platform
- The #1 Java EE application server, designed for the most Mission-Critical of applications
- Operations / Corp Architecture compliance – enterprise friendly
- Developer-friendly – shorter iterative dev, less runtime debugging Comprehensive command line, scripting and IDE support
WebLogic Server Clusters Coherence Data Grid WebLogic Differentiator: the “ilities” ©2010 Oracle Corporation Runtime Services / Build Env Databases Mainframes Legacy Commodity Virtualized
Modern Server Development on the Application Grid Build, automation, dependency, integration tools and testing tools ©2010 Oracle Corporation Runtime Services / Build Env Hudson WebLogic TopLink
Environment for Quick Application Grid Setup Leverage modular server download, install, and start-up
- Lightweight installers
- Optional service startup
- Fast deployment and server start
- Advanced Dynamic Class Redefinition
©2010 Oracle Corporation Runtime Services / Build Env
Build Edit Deploy Test Java EE 5 dynamic class redefinition (DCR) helps but... Oracle’s FastSwap ™ DCR far exceeds base Java EE 5 features Build Edit Test FastSwap DCR allows Java class shape change Iterate Application Grid Code Faster Debugging your application without re-deployment Java’s DCR limited to Java classes that retain their shape ©2010 Oracle Corporation Runtime Services / Build Env
©2010 Oracle Corporation
- Command-line/scripting tools for WebLogic domains
- Jython based
Faster Application Grid Configuration Management WebLogic Automation, Configuration Management Scripting Runtime Services / Build Env
- Memory is becoming exponentially cheaper
- Many applications are memory-constrained
- Traditional approaches alone can’t make effective use of huge memory
©2010 Oracle Corporation Source: pricescan.com Trend: The Cost of Memory is Falling Dramatically …but Java needs help in using it ©2010 Oracle Corporation Clustered Caching
- Memory spans multiple machines
- Automatically partitions and exploits all memory
- Add/remove nodes dynamically
- Reliability through redundancy
- Performance through parallelization
- Scale linearly to terabytes and thousands of nodes
©2010 Oracle Corporation In-Memory Distributed Computing with Coherence Cache huge data-sets in memory of multiple machines ©2010 Oracle Corporation Clustered Caching JRockit JRockit Coherence JRockit WebLogic Server
©2010 Oracle Corporation
- Clustered Data Management
- A single API for the logical layer, XML configuration for the physical layer
- Data Storage Options
Other IDE Basic Coherence Development Concepts/Features ©2010 Oracle Corporation Clustered Caching
©2010 Oracle Corporation
- Serialization Options
- Configurability and Extensibility
- Namespace Hierarchy
- Caching Strategies…
Other IDE Basic Coherence Development Concepts/Features ©2010 Oracle Corporation Clustered Caching
©2010 Oracle Corporation Coherence Cache Types / Strategies ©2010 Oracle Corporation Clustered Caching Replicated Cache Optimistic Cache Partitioned Cache Near Cache backed by partitioned cache LocalCache not clustered Topology Replicated Replicated Partitioned Cache Local Caches + Partitioned Cache Local Cache Read Performance Instant Instant Locally cached: instant --Remote: network speed Locally cached: instant -- Remote: network speed Instant Fault Tolerance Extremely High Extremely High Configurable Zero to Extremely High Configurable 4 Zero to Extremely High Zero Write Performance Fast Fast Extremely fast Extremely fast Instant Memory Usage (Per JVM) DataSize DataSize DataSize/JVMs x Redundancy LocalCache + [DataSize / JVMs] DataSize Coherency fully coherent fully coherent fully coherent fully coherent n/a Memory Usage (Total) JVMs x DataSize JVMs x DataSize Redundancy x DataSize [Redundancy x DataSize] + [JVMs x LocalCache] n/a Locking fully transactional none fully transactional fully transactional fully transactional Typical Uses Metadata n/a (see Near Cache) Read-write caches Read-heavy caches w/ access affinity Local data
- Larger application clusters can lead to database bottlenecks with traditional JPA scaling approaches like:
- Prior to TopLink Grid, there were two strategies for scaling JPA applications into a cluster:
TopLink Grid: Removing Database Bottlenecks ©2010 Oracle Corporation App Tier Clusters Data Tier Database Interface and Persistence
Scaling JPA with TopLink Grid
- TopLink Grid integrates EclipseLink JPA and Coherence
- Supports 'JPA on the Grid' Architecture
- Base configuration uses Coherence data grid as distributed shared cache
- Advanced configurations uses data grid to process queries to avoid database access and decrease database load
©2010 Oracle Corporation Interface and Persistence
TopLink Grid – Typical Configurations
- Grid cache – Coherence as shared (L2) cache
- Grid read
- Grid entity
©2010 Oracle Corporation Interface and Persistence
TopLink Grid with Coherence Cache Application EntityManager EntityManagerFactory L1 Cache Application EntityManager EntityManagerFactory L1 Cache Coherence ©2010 Oracle Corporation Interface and Persistence
How Is TopLink Grid Different from Hibernate with Coherence?
- Hibernate does not cache objects, it caches data rows
- Hibernate caches serialized data rows in Coherence
- Using Coherence as a cache for Hibernate
- Hibernate only uses Coherence as a cache—TopLink Grid is unique in supporting execution of queries against Coherence which can significantly offload the database and increase throughput
©2010 Oracle Corporation Interface and Persistence
Limitations in TopLink 11 g R1
- JPQL translated to Filter and executed in Coherence:
- Complex queries must be executed on database:
©2010 Oracle Corporation Interface and Persistence
Testing and Tuning in Today’s Enterprise Unit Testing User Interface Testing Integration Testing Load testing Security / Compliance Profiling and Runtime Instrumentation Open Source Testing Tools ©2010 Oracle Corporation Regression Testing Infinitest Jester MockRunner Oracle Testing/ Profiling Tools Oracle Load Testing Oracle Functional Testing Oracle AD4J Oracle JRMC HTTPUnit JUnit Selenium Testing, Diagnostics, Tuning
- Configuration Management
- Service Level Management
- Application Performance Management
- Lifecycle Management
- Dashboards
- AD4J
- Diagnose problems in production
- View all java activity: instrumentation not needed
- Trace transactions across tiers, into the Oracle DB
Application Diagnostics for Java (AD4J) Application performance management solution ©2010 Oracle Corporation Testing, Diagnostics, Tuning Operating Systems Database Middleware Applications
Deploy Escalate Analysis Profiling & performance tuning Regression testing Troubleshooting Monitoring Alerts & triggers Diagnostics with Oracle JRockit Mission Control ©2010 Oracle Corporation Testing, Diagnostics, Tuning Operations Production diagnostics Development
- On-demand development environment provisioning
- Fast pilots, prototyping
- Eliminate delays from:
- Challenge: Connectivity to enterprise resources
Hypervisor JRockit VE Application(s) Machine Resource Pool Virtualized Managed Server WebLogic Cluster How Can Cloud Computing Help FMW Developers? ©2010 Oracle Corporation
Application Grid: Fast Provisioning / Deployment Fusion Middleware Appliance Builder ©2009 Oracle Corporation Oracle Confidential WebLogic Suite-based Application Grid on Virtualized Infrastructure Production Environment Appliance Builder Dept App Development Environments Dept App Custom code and environment description Dept App Dept App Enterprise Manager
Your Network Debug / Deploy Public Internet IDE Tools on your desktop Debug / Deploy Remote Server (s) AMAZON EC2 Instances Amazon EBS Other IDE Public Cloud Development Scenario A ©2010 Oracle Corporation Cloud – App Grid Deployment Oracle Enterprise Linux WebLogic Server
Public Cloud Development Scenario B Your Network Public Internet AMAZON EC2 Instances WebLogic Server Amazon EBS VNC Other IDE ©2010 Oracle Corporation Cloud – App Grid Deployment Oracle Enterprise Linux
Application Grid Agenda & Roadmap ©2010 Oracle Corporation ©2010 Oracle Corporation Testing, Tuning, Diagnostics Cloud – App Grid Deployment 1. Why App Grid? 2. Roadmap 3. Conclusion
In Review ©2010 Oracle Corporation
- Your choice: JDeveloper or Eclipse
- Scale JPA applications with Grid
- No rewrite for performance
- Automated cache management
- Spring Framework integration
- Leverage server virtualization
- Clients for Java, .NET, C++
Application Grid Development
For More Information ©2010 Oracle Corporation search.oracle.com application grid or www.oracle.com / goto / application grid

Enterprise Development Strategies for Java, WebLogic Server, and the Oracle Fusion Middleware Stack

by Oracle Technology Network

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 39

Statistics

Enterprise Development Strategies for Java, WebLogic Server, and the Oracle Fusion Middleware Stack Presentation Transcript