Category: Education

Presentation Description

No description available.


Presentation Transcript


LEAF Building Enterprise-Class Applications with a J2EE Framework Guest Lecture Trusted Component Course ETHZ, 8.1.03 Philipp H. Oser, ELCA

Context : 

Context ELCA Independent Swiss IT provider Over 300 highly skilled Engineers Lausanne, Zurich, Berne, Geneva, London, Ho Chi Minh City Wide spectrum of competencies architectures & distributed systems project supervision system integration content management internet technologies quality resource planning


Context Context Company building Enterprise Applications for clients Development platforms are today essential for Enterprise Applications Usually: client chooses development platform

Presentation Overview: 

Presentation Overview Part I: Introduction to the LEAF J2EE platform J2EE and current IT challenges LEAF: a J2EE enhancement framework Part II: Concrete experience Part III: How a J2EE framework helps to develop robust components

Part I: Introduction to the LEAF J2EE platform: 

Part I: Introduction to the LEAF J2EE platform

Current challenges in IT: 

Current challenges in IT Complexity and heterogenity many systems, many technologies legacy data and transactions are here to stay interconnections everywhere Economical and technological changes new technologies must be leveraged investments must be preserved vendor dependencies must be controlled agility is vital Pressure on scalability, security and robustness ever increasing user population ubiquitousness of IT (Internet...) increasing dependency on IT infrastructure

Java 2 Enterprise Edition (J2EE) A powerful platform: 

Java 2 Enterprise Edition (J2EE) A powerful platform

J2EE meets many of these challenges: 

J2EE meets many of these challenges Complexity reduction homogeneous runtime environment (the JVM) standards for integration and interoperation abstractions help developers to focus on business logic Stable enterprise platform high level of vendor independence through standards (APIs, models,...) improved maintainability (separation of concerns, portable skills...) excellent market acceptance Robust distributed computing powerful distributed component model (EJB) good architectural match for current e-applications

But J2EE is not perfect: 

But J2EE is not perfect Some J2EE issues that are relevant to us: Vendor independence? Really? proprietary features, early support for emerging functionality differing interpretations Lack of support for crucial features ORB instrumentation and pluggable behaviors batch jobs, daemons, singletons, background processes Restrictions of the EJB model inflexible technical services no threads, no native code, no sockets, no files, ... Usability issues rich platform -- not enough guidance support for best practices ...


Framework Overview (1/2) LEAF is a component framework for building distributed applications based on new components and legacy resources LEAF encapsulates and extends the Java 2 Enterprise Edition platform Your application

Framework Overview (2/2): 

Framework Overview (2/2) LEAF := J2EE - issues + Architectural blueprint and guidelines Service integration platform a thin abstraction layer on top of the J2EE ORB a light service infrastructure integration framework Technical services to complement the J2EE Presentation frameworks (GUI, Web, Mobile) Build system and development tools

Framework benefits: 

Framework benefits Enhances J2EE implementations Fully leverages the power of J2EE Avoids vendor lock-in Protects against the volatility of J2EE specification and products Compensates limitations of the EJB model Scalable and fault-tolerant container extension to host functionality not possible in EJB More flexible technical services Enhances platform agility Built-in extension and instrumentation mechanisms Modular, product-neutral build and deployment

Features overview: 

Features overview

Reference architecture: 

Reference architecture Multi-tiered, multi-channel Service-oriented Component-based Flexible mapping scenarios Best practices and architectural patterns

Services framework: 

Services framework Client-server interactions are modeled as services Services can be located anywhere -- transparently Local services are managed by LEAF Multiple service infrastructures are supported (local services, EJB, COM, CORBA, SOAP) New service infrastructures can be added => Service Location/ Implementation Transparency Client EJB container CORBA / COM server SOAP server

Extensibility mechanisms: 

Extensibility mechanisms Invokers Transparently add pre- and post-processing to any service Can be chained Can be deployed at configuration or at run time E.g., logging, auditing, load-balancing, version switching Implicit context passing Added transparently to each call Allows client and server to share technical info (e.g. security, transactions,...) JVM EJB container invokers stubs invokers skeleton EJB Client


Limitations for EJB components No long-running processings No singleton semantics No daemons No use of threads, no access to files, no JNI, no server sockets Inconveniences: EJB-external solutions possible, but inhomogeneous programming model (for writing and using components) no component model no component execution environment Extended container: Rationale

Extended container: 

LEAF extended container Extended container The container extension provides a run-time environment for all services that do not fit in the EJB model Can run batch processors, daemons, listeners, schedulers, etc... Has monitoring, checkpointing and failover capabilities Can balance load across multiple nodes Uses the same programming model as the other services


Enhanced J2EE implementation compatibility LEAF isolates applications from: Proprietary container extension for lacking J2EE support, e.g., security extensions, management extensions, web-service support Unspecified parts in the J2EE specification, e.g. container-specific deployment descriptors (e.g., JNDI names) different build and deployment processes Evolving J2EE specs Means: Abstraction Own light mechanisms Build scripts


Additional technical services Key LEAF services Tracing and checking Unified naming Configuration Notification Dynamic authentication and authorization User session management Extensible scheduling Pooled DB-independent data access Performance measurement Batch service

Part II: Concrete experience: 

Part II: Concrete experience

Experience with LEAF: 

Experience with LEAF LEAF was used in several projects so far: Slight initial resistance Unanimously cited as key success factor at project debriefing Typical projects with concrete benefits E-business server Application Integration

E-business server (1): 

E-business server (1) Challenges Heterogeneous environment Importants load Large team, short lead times High reliability requirements Solution Multi-channel integration architecture Reusable technical services Iterative development

E-business server (2): 

E-business server (2)

Application Integration: 

Application Integration Vision Multi-tier service architecture based on J2EE Clear separation between existing enterprise system and new business systems Integration layer for homogeneous access to existing enterprise systems Shared technical services integrated in Hub (security, db access, notification) Steps Proof of technology/ concept Measurement campaign and performance estimations First iteration of Hub based on LEAF

Concrete experiences (1): 

Concrete experiences (1) Improved J2EE implementation compatibility Immature and unergonomic EJB container was replaced by light and mature container for development, e.g., code/ test cycle cut back from 1.5 hours to 20 minutes savings on licence and infrastructure costs Light deployment of backend system (e.g. on Laptops) Invokers serialization/ idempotency of requests from CMS session data loader (CMS had no server affinity) authorization added on already developed business services notification of all unchecked exception to NT event log performance measurement added during integration

Concrete experiences (2): 

Concrete experiences (2) Existing LEAF parts Architecture, technical services, support frameworks LEAF layer and naming service workaround for some EJB container "features" (e.g. wrapping/unwrapping RT exception in app server) JNDI initial context loaded transparently on Websphere cluster Encapsulation and abstraction of EJB developers were effectively shielded from technical problems non-EJB developers were more rapidly productive

Concrete experiences (3): 

Concrete experiences (3) Service location transparency Same service interfaces for different deployment scenarios (e.g., with/ without EJB container) Service implementations movable (e.g., against bad performance) Batch framework and container extension reliable batch jobs out of the box integrated with legacy scheduler

Lessons Learned: 

Lessons Learned Expect to refactor each component 1-2 times until you understand what it should look like Frameworks of this kind are not well accepted by developers “Toothbrush” analogy Framework developers must tolerate a lot of critique If a encapsulated platform has a bug, the problem falls back at the framework For a new project that uses the framework, it is highly recommended that a framework expert supports it =>A strong management commitment is crucial

.NET framework challenges the J2EE: 

.NET framework challenges the J2EE New framework evolving: The .NET framework: Similar to J2EE in goals and architecture Objective: become best enterprise application platform .NET is technologically more advanced Evolution of many J2EE concepts Java, VM, architecture, powerful class library Many of LEAF’s concepts are already in .NET pluggable interoperation protocols, invokers (interceptors) .NET can not be "avoided" An integral part of the future versions of Windows The IT platform landscape will be bipolar

Framework evolution: 

Framework evolution LEAF proved extremely valuable reference architecture and reusable code infrastructure proactive acquisition of core competencies Founding principles are platform-independent the framework can be extended to other domains (e.g. mobile and .NET) Not a unified platform, but: shared architectural reference model shared technical concepts interoperability

Part III: How a J2EE framework helps to develop robust components: 

Part III: How a J2EE framework helps to develop robust components

Technical means for application quality: 

Technical means for application quality Modular build system Module = collection of services, associated classes, default configuration, makes dependencies (to external libraries, other modules) explicit Module is granularity of reuse For independent builds, service evolution, modularity in projects Development tools Global tracing with extensive information on what is going on Design by contract library

Technical means for application quality: 

Technical means for application quality Testing Automated test framework JUnit based Each module defines its tests, all present modules are tested with one command Framework controls the environment (database, other required modules) Distributed test framework (to test fault-tolerance)

Technical means for application quality: 

Technical means for application quality Light abstraction of the underlying platform Fixing bugs/ "features" of underlying plattform, e.g., Passing back RuntimeException to EJB bean clients Fixing non-J2EE conformance of Websphere Oracle BLOB bugs Isolation of platform changes EJB component model evolves quickly Simplification of platform no Home IFs no deployment descriptors (unless exotic) simplified technical services/ convenience services Platform vendor independence Improved application agility

Technical means for application quality: 

Technical means for application quality Reuse of technical components & know-how Reuse leads to components that are tested in more different environments For reuse in heterogeneous environment, a standardized platform a prerequisite J2EE spec a good start, but not sufficient; J2EE implementations are too different Other environment dimensions: databases, operating systems, JDKs Experience collection Recurring problems are solved in the framework Design patterns included in platform (for homogeneity & simplicity) Service Locator Business Delegate Service Activator Best practices included (code & guidelines)


Conclusions LEAF is very useful for us More than 10 times reused Benefits: quickly up to speed design and development efficiency gained application quality and flexibility complexity management reuse of know-how and components Approach of leanly wrapping an emerging enterprise platform is worthwhile Abstraction allows simplification, problem containment, flexibility Other J2EE enhancement frameworks emerge currently Future: We continue to use and extend LEAF LEAF.NET and LEAF mobile are already well advanced

For more information: 

For more information LEAF site on ELCA’s homepage http://www.elca.ch/Home/Solutions/Technology_Frameworks/LEAF/index.php Available resources: EDOC 2002 paper: The LEAF Platform: Incremental Enhancements for the J2EE LEAF J2EE datasheet LEAF .NET presentation My email address: pos@nospam.elca.ch (without the “nospam.”)

Thank you for your attention: 

Thank you for your attention

Meeting the .NET challenge (2): 

Meeting the .NET challenge (2) SQL server RDBMS Processing Processing Presentation Presentation J2EE .NET

J2EE vs .NET: 

J2EE vs .NET .NET advantages for framework developers: Multi-language Languages conceptually more advanced unsafe (memory access) and unmanaged (simplified JNI) code attributes (metadata) delegates (synchronous/ asynchronous calls, Observables) Multi-transport protocol (transport: HTTP/ TCP, format: SOAP/ Binary) Switch between a Web and GUI presentation tier easier Interface between database and processing tier more advanced and potentially more performant AppDomains := Code compartments allow running an n-tier application in 1 process, automatic serialization/ interception between compartments


J2EE vs .NET J2EE advantages for framework developers: Maturity 2-3 years advantage (particularly on business tier: WMI, component framework) Inherently multi-platform Implementations from multi-vendors Distributed component model (EJB) is more advanced no business-tier “container” in .NET (but less important there) Java Connector Architecture (JCA) Not from Microsoft


Architecture Block diagram: N3 N2 N1 N0 site site site site site site Container extension Cejb GUI JDI part Leaf part

GUI architecture: 

GUI architecture Block diagram Now In the future ?

authorStream Live Help