Regnet Specification : Technical point of view REGNET

Contents Technical architecture Process e-Business architectures Regnet Technical Architecture

Technical architecture

Technical 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.

Process UP : Elaboration phase Technical Requirement Technical architecture Risks identification Architecture validation

Technical 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 will not integrate at all with other technologies and in the overall architecture...

Technical 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

Technical 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 a limited 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.

Technical 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.

E-Business architecture

Directory and Security Platform Engineering point of view Internet Web Clients Desktop Clients Data acquisition ? Embedded Clients Wap or PDA ? B2B Web Application Platform Desktop Application Web Application Embedded Application e-Service Integration and Automation Platform Connector Database Z39.50 Existing Application Workflow and Process Automation Publication … Data Services Enterprise Business Components Directory Organization And Schema Security Policies

Web App. Cluster Deployment Infrastructure ?? Directory and Security Server Internet, or Extranet Web Clients e-Service Clients Web App. Cluster Integration and Automation Server Connector Database COTS Application Existing Application Network Central Data Center Connector Third Party e-Services Web Application Server Regional Office Desktop Clients

Component based technical architecture

Distributed object structures Name Trans. Pers. Secu. Even t Legacy systems Technical Services Infrastructure Business objects You must write : your business object Integration code Services DataBase

RMI or CORBA distributed structures NameTrans. Pers. Secu. Even. Standard technical services Infrastructure Business objects This is the case for CORBA and RMI You must write : your business object integration code Legacy systems DataBase

Application servers Business logic integration Container Component container (EJB, Servlets/JSP...) You must write : Your business object a standard technical descriptor NameTrans. Pers. Secu. Even. Standard technical services Legacy systems DataBase

Descriptor 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

Componants 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 Client Container automated infrastructure Component implementation of the business logic The container acts as a distributed server object Server network Persistence Transaction Directory Services Infrastructure APIs Stub (proxy) transparent localization

Java 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

Java 2 Enterprise Edition

J2EE 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 Description + assembly instructions A A B B Module Application description Enterprise Archive (ear)

The 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

J2EE 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…)

Regnet technical architecture

TOOLS (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

TOOLS (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 ?…