PDF
HistoryProposition of Merge of AIT and UJF Branches
- 1 Current Status
- 2 Proposition of Merge
- 3 Roadmap for the merge
- 3.1 General
- 3.2 Reader Core Proxy
- 3.3 Sensor Proxy
- 3.4 IOs (Actuator) Proxy
- 3.5 RFID Printer Proxy
- 3.6 ALE Server
- 3.7 EPCIS
- 3.8 BEG
- 3.9 ONS
- 3.10 NFC Stack
- 3.11 End-to-End Management
- 3.12 Tooling
- 3.13 Generic User Console (GWT-based)
- 3.14 Demo packs
- 3.15 Demonstrations
- 3.16 Others
- 3.17 Non functional requirements
- 3.17.1 Security
- 3.17.2 Privacy
- 3.17.3 Reliability
- 3.17.4 Scalability
- 3.17.5 Determinism
- 3.17.6 Mission-critical
- 3.17.7 Portability
- 3.17.7.1 Operating systems : Windows vs Linux
- 3.17.7.2 JVMs : J9, JamVM, Sun, JRockit, ...
- 3.17.7.3 OSGi platforms: Equinox, Felix, ...
- 3.17.7.4 JavaEE servers (for EPCIS, ONS and ALE server): JOnAS, JBoss, Glassfish, ...
- 3.17.7.5 DBMS (for EPCIS, ONS) : MySQL, PostGres, Oracle, Derby (aka JavaDB), HSQL, ...
- 3.17.8 Misc
Under construction
1 Current Status
Two branches coexist in the OW2 Aspire RFID project- AITdev (AIT) branch focuses on …
- RFIDSuite (UJF) focuses on …
2 Proposition of Merge
2.1 AIT branch will provide
- Reader Core Proxy
- Exists within OSGi
- Provides JMX management interface
- Provides EPC Reader Management (not currently enabled and used)
- ALE communicates with it via EPC Reader Protocol
- Provides Interfaces with readers:
- For Intermec(BRI)
- For Impinj (Mach1)
- For FossTrack’s Simulator reader
- HAL Wrapper for new readers
- ALE Server
- EPC F&C1.1 standard compliant.
- Check if AspireRFID fully supports Tag Memory Specification API (Section 7 of ALE 1.1 specifications)
- ALETM – Main API class (Section 7.1 of ALE1.1 specifications) and implement it if it doesn’t.
- Check if AspireRFID fully supports Tag Memory Specification API (Section 7 of ALE 1.1 specifications)
- Runs on Apache tomcat 6.0
- Uses CXF and spring to implement JaxWS for the control interface.
- It Supports Maven.
- Supports RP and LLRP for the communication with the readers.
- Supports TCP/HTTP protocol to deliver EC reports
- Provides Standard EPC Control Interface Based on SOAP messages
- EPC F&C1.1 standard compliant.
- EPCIS
- EPC 1.0.1 standard compliant
- Provides Extension Mechanisms
- New Event Field A new field may be added to an existing Event Type in the Data Definition Layer. Additionally to every event the following data are supported from the repository (check Section 6.3 and 9.1 of the EPCIS specifications):
- Provides Extension Mechanisms
- EPC 1.0.1 standard compliant
| Column Name | Type Name |
|---|---|
| event_id | BIGINT |
| fieldname | VARCHAR |
| prefix | VARCHAR |
| intValue | INT |
| floatValue | FLOAT |
| dateValue | TIMESTAMP |
| strValue | VARCHAR |
- Runs on Apache tomcat 6.0
- Uses CXF and spring to implement JaxWS for the query and capture interface.
- Uses SQL for the query interface and Hibernate for the capture interface.
- Supports MySQL 5.0
- Provides standard EPC Query and capture Interface Based on SOAP messages.
- Provides proprietary master data capture interface.
- BEG (under development)
- Tooling (Eclipse) ASPIRE IDE has been designed as an Eclipse RCP (Rich Client Platform) application that will run over Equinox OSGI server. It uses the command API to define menus, pop-up menu items and toolbars so as to support easily plug-ins and provide more control. Every tool will be an eclipse plug-in/bundle that will be able to be installed or removed as needed.
- AspireRfidIDE Core
- ALE Server Configurator Plug-in
- Business Event Generator Plug-in
- Physical Reader Configuration & Management Plug-in
- EC-Spec Editor Plug-in
- LR-Spec Editor Plug-in
- Master Data Editor Plug-in
- Connector
- Connector engine component
- Connector client component
2.2 UJF branch will provide
- Plug and Play Sensors (using iPOJO+WireAdmin+WireAdminBinder) : data collected for sensors must be add in the extension element of the ECReport.
- EPCIS extension to store sensors data (position, measurement, answers to survey, …) : the data must be extracted from the ECReport by the EPCIS.
- GWT-based User Console relying on the RFIDSuite” EPCIS (developed with EJB3.0)+ extensions (sensors data) : should we keep/discard the “Warning ” features (lost objects, pairing, …): they will be replaced by the BEG, isn’t it ?
- Edge Premice Server Architecture ??? Question: does the AIT branch can model the 3 layer architecture ?
- Communication (JMS, HTTP/SOAP, SMTP, XMPP) between Edge and Premice and between Premice and EPCIS to transport ECReports
- « ONS » based on Web Services and EJB3.0 + WS-Metadata (JSR 181).
- Porting the existing readers (Tagsys, TIRIS, ACS122, Mir:ror) to the HAL wrapper
- Bluetooth bridge as a reader
- HTTP bridge as a reader
- NFC MIDLets
- with BT to the Bluetooth Bridge
- with HTTP to the HTTP Bridge
- Management and deployment :
- LDAP for X509 certificates publication and for architecture description
- JMX for configuration and monitoring
- use Felix MOSGi project for the JMX agent
- may be UPnP and DNSSD for Edge and premice mutual dynamic discovery in the warehouse/store network)
- JVisualVM and JConsole plugins for OSGi management (may be contributed to the Apache Felix community).
- Generic build for demopacks (ANT, JMX (and IzPack in the future))
2.3 Common programming practices
2.3.1 Maven
The 2 branches are already built using Maven 22.3.2 JavaEE
TBD2.3.3 JMX
The 2 branches have already MBeans to manage MW components2.3.4 OSGi
The 2 branches have already packaged applications as OSGi bundles2.3.5 iPOJO
Apache Felix iPOJO is a component model to ease the development of OSGi applications. It deals with the service dependency management, the JMX MBean definition for OSGi component, the configuration, … iPOJO was mainly developed by the Adele team involved in the Aspire project. iPOJO is already used in the services of the JOnAS 5 JavaEE server. Most of the bundles of the RFIDSuite branch are developed with iPOJO. A 10 minute tutorial on iPOJOWe propose to use intensively the iPOJO component model for all bundles produced by the project.3 Roadmap for the merge
3.1 General
- Port all OSGI services to iPojo 1.0
3.2 Reader Core Proxy
- Port UJF readers to AITdev
- Read semi-active tags to read sensor data
3.3 Sensor Proxy
- Propose an extension model for sensor data and integrate to the reader core proxy or ALE
- Integrate Zigbee sensors to the model
3.4 IOs (Actuator) Proxy
- TBD
3.5 RFID Printer Proxy
- TBD
3.6 ALE Server
- Use the AITDev ALE server
3.7 EPCIS
- Deploy AITdev EPCIS on JONAS
3.8 BEG
- Use the AITDev BEG server
- connection with OW2 Bonita ??
3.9 ONS
- Keep UJF ONS and implement ONS specification interfaces (based on DNS?)
3.10 NFC Stack
The NFC stack clusters all SW bricks to build NFC applications on the phone and on the desktop or local server.3.10.1 Common
- new NDEF RTD : GPS position, Point of Interest, Located Smart Poster, BT/Wifi access point (useful to avoid long initialization sessions due to scan all the device) ...
3.10.2 MIDLet (J2ME)
- NFC utilities ((JSR 257)
- Geolocation utilities (JSR 179 and JSR 293)
- Sensor utilities (JSR 256)
- Map display (from open map repositories)
- GPS logger/replay
- GPS track interactive simulator
- Peer-to-peer utilities
- Rating utilities : for social networking (people rating), product rating, maintenance, ...
3.10.3 Desktop (JavaSE)
- BT-ALE bridge (JSR82)
- Phone-to-Desktop utilities
3.11 End-to-End Management
- Use Jasmine (eclipse plug-in) for management
- Maybe use gvisualvm (for monitoring)
- Implement JMX for UJF Museum
- Try to make new standard for Reader Management (RM) based on JMX
3.12 Tooling
3.13 Generic User Console (GWT-based)
- Make UJF applications connector based
3.14 Demo packs
- Create a project to build demos.
