1 / 12

OSGi End 2 End Committee - Remote Management

OSGi End 2 End Committee - Remote Management. March 1st & 2nd, 2007 Cologne, Germany. Attendees. Ryutaro Kawamura, NTT Hiroyuki Maemichi, NTT Haejun Yi, ProSyst Technology Korea Olivier Gandit, Sirlan Technologies Frank Mittag, SAP Andreas Kraft, Deutsche Telekom

donyaa
Download Presentation

OSGi End 2 End Committee - Remote Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OSGi End 2 End Committee - Remote Management March 1st & 2nd, 2007 Cologne, Germany

  2. Attendees • Ryutaro Kawamura, NTT • Hiroyuki Maemichi, NTT • Haejun Yi, ProSyst Technology Korea • Olivier Gandit, Sirlan Technologies • Frank Mittag, SAP • Andreas Kraft, Deutsche Telekom • Sylvain Marie, Schneider Electric • Miguel Garcia Longaron, Telefonica I&D • Guillaume Sauthier, Bull • Willem Acke, Alcatel-Lucent • Chris Gray, /k/ Embedded Java Solutions • Peter Kriens, OSGi-Alliance • Dimitar Valtchev, ProSyst Software GmbH • Kai Hackbarth, ProSyst Software GmbH • Tim Bolduc, Delphi • Subramanian Krisnamoorthy, Samsung

  3. Agenda March 1st • 10.30 Welcome • 10.45 Introduction OSGi-Alliance • 11.15 Participants Presentations • Ryutaro Kawamura, NTT • Willem Acke, Alcatel • Olivier Gandit, Sirlan Technologies • Sauthier Guillaume, Bull • Migual Garcia Longaron, Telefonica • 13.00 Lunch • 14.00 Open Discussion • brainstorming on topics that E2E Committee should work on • Look for common interest of areas • 17.30 End of Day 1 • 19.00 Dinner at Anno Pomm (Potato Restaurant)

  4. Agenda March 2nd • 09.30 Prioritizing ideas • 10.30 Continued open discussion based on priority • 12.30 Lunch • 13.30 OSGi organization, technical process, IPR overview, next steps • 15.00 Adjourn

  5. Architecture Requirements (1) • Multiple service provider should have separated and secured areas on one and the same OSGi-Platform(10) • Security of managed areas should be remotely manageable • OSGi Management Object Model(9) • Mappable to TR-069,OMA DM, etc. • Device description framework • Centralized Management of OSGi Platforms supporting different domain management protocols(7) • Server side management services • Remote Management must be communication channel agnostic and support different channels(7) • Management on Business level(7) • Business logic • Grouping a set of artifacts and their configurations • Remote Management Reference Architecture(7) • Incl. SG Management, Service Providers, Devices, etc. • Single and distributed application programming and deployment model(7) • Flexible deployment policies

  6. Architecture Requirements (2) • Usability of the Permission Admin Model(5) • User subscription model(4) • Incl. Authorization and authentication • Intial Provisioning outside the OSGi framework(2) • Manage non-OSGi artifacts(1)

  7. Framework & Bundle Related • Support for Transactions(10) • Distributed management operations that have acid-properties • Save and restore system states(9) • Automatic rollbacks • Remote monitoring, diagnostics and invocation(9) • E.g. Events, Logs • Remote Management Specification must use OSGi Configuration Management(2) • OSGi Framework must collect usage information for e.g. billing(2) • Provide events for remote management operations(1)

  8. Protocol Related • Secure, authenticated and encrypted communication (11) • Single Sign On • Remote Management Server to OSGi-Framework • Firewalls should be taken into account(8) • IPv6 support(3)

  9. Backend Related • Remote Management specifications must not block any scales(7) • OSGi Framework and Services Registration(7) • Incl. Indentification & Authentication • Grouping of OSGi-Frameworks, which have the same management configuration(5) • Repository Administration(3)

  10. Next Steps • The group will write one RFP for all requirements until end of May • The group has two more conference calls and one F2F meeting • Conference Calls on March 30th and April 20th • F2F meeting on May 10th in Cologne • Creation of the Remote Management Expert Group (RMEG) • BoD approval of the Charter of RMEG

  11. Remote Management RFP Responsibilities • OSGi Management Object Model • Telefonica and Alcatel-Lucent • Centralized Management of OSGi Platforms supporting different domain management protocols • Telefonica and ProSyst • Remote Management must be communication channel agnostic and support different channels • Deutsche Telekom • Multiple service provider should have separated and secured areas on one and the same OSGi-Platform & Management on Business Level • NTT and SAP • Remote Management Reference Architecture • NTT, Telefonica, Sirlan Technologies & ProSyst • Single and distributed application programming and deployment model • Sirlan Technologies and Peter Kriens • Support for Transactions • Sirlan Technologies and Peter Kriens • Remote monitoring, diagnostics and invocation • Telefonica and Deutsche Telekom • OSGi Framework and Services Registration • ProSyst

  12. Proposed Charter RMEG The Remote Management expert group will create a functional model for remote management of open services gateways and their services. This model will resolve the requirements of interoperation with existing management systems and protocols, the need to remotely manage services life cycles, the need for large-scale deployments, and the needs for adequate security on management operations. The Market Requirements group may identify other critical remote management needs. If approved by the membership, the Remote Management Functional Specification will serve as the base for API definitions.

More Related