Title: Regnet Specification : Technical point of view
1Regnet Specification Technical point of view
2Contents
- Technical architecture
- Process
- e-Business architectures
- Regnet Technical Architecture
3Technical architecture
4Technical Architecture
- Technical architecture present building blocks of
software that we used in order to implement
functions. Two technical architectures - Engineering point of view independent of the
technologies - Technological point of view gives technologies
used. - System architecture gives projection of the
technical architecture on material.
5Process
- UP Elaboration phase
- Technical Requirement
- Technical architecture
- Risks identification
- Architecture validation
6Technical Architecture How?
- Objectives
- Have a selection process for your development and
deployment tools. - Identify alternative solutions in case problems
arise. - Define your selection criteria.
- The independence rule.
- Avoid Software Mainframe Syndrome
- Avoid being locked with proprietary solutions
- Don't try to predict the future.
- Integration is the price to pay for freedom
- Technical Integration is an essential criteria.
- One technology may be the most efficient but
willnot integrate at all with other technologies
and inthe overall architecture...
7Technical Architecture Designing the Integration
- Designing the integration is to define the way
the system will work as a whole. - Define collaboration between different products.
- Define at the very beginning the constraints that
the architecture will put on the model and the
implementation. - You will certainly have to define elements that
will glue the components together - Interfaces.
- Classes.
- Macros/Templates.
- Modeling and coding standards.
- Development tools with user guides.
- Build management facilities
8Technical Architecture Prototyping
- Objectives.
- To validate the design of the integration layer
against requirements. - To cope with integration risks.
- To build the complete list of constraints that
architecture puts on detailed design. - Only trust what you see.
- The architecture prototype must implement
alimited part of the business model. - A vertical slice of 5 to 15 classes.
- Validate the Architecture from end to end.
- Apply load tests, fault-tolerance tests, and so
on - Define the path from Analysis to Implementation.
9Technical Requirements
- Data Access.
- Logon/Sessions management
- Concurrency control
- Transaction management
- Security.
- Authentication
- Access control
- System Management.
- Active servers list
- Starting/Stopping servers
- Alarms
- Dynamic load balancing
- Special management protocols SNMP, CMIS/CMIP
- Lifecycle.
- Creation
- Search
- Localization
- Destruction
- Distributed memory management
- Separation between database object lifecycle and
in-memory object lifecycle - Trace and debugging.
- Availability, Fault-tolerance and cold/warm
restart facilities.
10E-Business architecture
11Engineering point of view
Desktop Clients Data acquisition ?
Internet Web Clients
Integration and Automation Platform
Web Application Platform
Embedded Clients Wap or PDA ?
e - service
B2B
consumer
Directory and Security Platform
12Deployment Infrastructure ??
Directory and Security Server
Internet, or Extranet Web Clients
Web App. Cluster
Network
e-Service Clients
Web App. Cluster
Integration and Automation Server
e - service
Web Application Server
consume
Desktop Clients
Central Data Center
Third Party e-Services
Regional Office
13Component based technical architecture
14Distributed object structures
- You must write
- your business object
- Integration code
- Services
Business objects
Legacy systems
Infrastructure
DataBase
Name
Trans.
Pers.
Secu.
Event
Technical Services
15RMI or CORBA distributed structures
- You must write
- your business object
- integration code
Business objects
Legacy systems
Infrastructure
Name
Trans.
Pers.
Secu.
Even.
DataBase
Standard technical services
- This is the case for CORBA and RMI
16Application servers
- You must write
- Your business object
- a standard technical descriptor
Business logic integration
Business contract
Business contract
Legacy systems
Container
Name
Trans.
Pers.
Secu.
Even.
DataBase
Standard technical services
- Component container (EJB, Servlets/JSP...)
17Descriptor as a technical contract
- The object implements the business contract
- Published business interface
- Business code
- The descriptor describes the technical contract
- Life Cycle How was I created ? Destroyed ?
Passivated ? Found ? - Transactions Are my operational transactional ?
Who can see my modifications ? - Concurrent access Can multiple clients access
me at the same time ? - Persistence Should my state be saved in a
persistent storage ? - Security Who is allowed access my services ?
- This technical contract will be automatically
implemented - At deployment-time, and provided to the container
18Componants and containers
- The component
- distinguishes interface and implementation
- the implementation is instantiated into a server
side container - The container
- intercepts the communications between the client
and the component in order to enable framework
code automation, such as transactions and
persistence management - Communicates with the component by using direct
function calls
Container automated infrastructure
Services Infrastructure APIs
Server
Client
Directory
network
Transaction
Persistence
Stub (proxy) transparent localization
The container acts as a distributed server
object
Component implementation of the business logic
19Java 2 Enterprise Edition
- Java Enterprise Platform
- Superset of Java 2 Standard Edition (J2SE,
ex-JDK) - Integrates business (EJB), and Web (Servlet/JSP)
component containers,and several other Java APIs
- J2EE is managed as a full release
- Specification
- Reference Implementation
- Compatibility tests and label
20Java 2 Enterprise Edition
21J2EE Application
- What is an J2EE application ?
- A set of component modules
- An application is deployed into a J2EE server
- It can also be directly deployed as an
"standalone" module
Component
Module
Application
Enterprise Archive (ear)
A
Description
A B A?B
Application description
Description assembly instructions
B
22The EJB standard
- Model for business components
- Java Standard
- Specifies interfaces provided by a business
component container - The vendors provides compliant implementations
- No link with JavaBeans (GUI components) !
- More than 35 editors provide containers compliant
with the EJB specification - Objectives
- Allow business components reuse without code
access - Simplify components and applications development
- Let IS suppliers manage complex enterprise IT
issues - Standardize Java application servers
- The heart of the Java enterprise platform
- Since 1998
- Defined by Sun in partnership with IBM, Oracle,
BEA and many others
23J2EE today
- Industry key needs for the future
- Compliance to the J2EE platform
- Vertical components
- Component-based development cycle (tooling)
- J2EE simplifies project development but
- e-business projects are getting more complex
- Internet/Web, transactions, workflow, B2B, EAI,
persistence - Design phase is critical
- Blindly following the standard can lead to an
dead-end - The experience of J2EE applications is an
advantage - Choosing a product is critical
- Variable support for standards (amount of
support, versions...). - A significant part of e-business projects does
not rely on standards only (personalization,
portals)
24Regnet technical architecture
25TOOLS (1)
- Presentation
- WebServer Apache
- Server Page JSP (Tomcat), PHP
- WAP, PDA
- Data and MetaData acquisition
- MetaData
- XML editor
- Harvester
- 2D or 3D data Applet Java 2D or 3D upload
servlet - Application server
- Jboss
- Enhydra
- Data access
- DataBase MySQL (transaction ?), PostgreSQL
- O/R Mapping Castor
26TOOLS (2)
- Connectors
- Legacy
- Z39.50
- B2B infrastructure Web services
- ebXML cf. Task 1.3
- JBOSSSoap Zero-Effort Object Access Package
(ZOAP) - B2B sophisticated functionalities
- Workflow engine WFTK (Open-source workflow
toolkit) - Development tools
- Java IDE SUN/Forte for Java
- ?