search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

Reference to TR-157 objects #1837

Closed bjhargrave closed 13 years ago

bjhargrave commented 13 years ago

Original bug ID: BZ#1969 From: Kai Hackbarth <k.hackbarth@prosyst.com> Reported version: R4 V4.3

bjhargrave commented 13 years ago

Comment author: Kai Hackbarth <k.hackbarth@prosyst.com>

Need to add appropriate references to TR-157 object to enable the ACS to correlate to OSGi specific service objects.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

I have a few questions here:

  1. is it for target milestone 4.3? Please, update.
  2. "references to TR-157" - That means an update of TR-069 PA Guideline, TR-069 Software Module Object mapping? If yes, we need more details: 2.1 Device.SoftwareModules.ExecutionUnit.{i}.References can points to: --- only one OSGi.{i}.BundleState.{i}. instance - the same bundle must represent ExecutionUnit and BundleState --- a few OSGi.{i}.ServiceState.{i}. instances - ExecutionUnit bundle must be the provider of all service instances --- a few OSGi.{i}.PackageState.{i}. instances - ExecutionUnit bundle must be exporter of all packages 2.2 How can link Device.SoftwareModules.ExecEnv.{i}. with OSGi.{i}.? There is no execution environment reference.
bjhargrave commented 13 years ago

Comment author: william.lupton@pace.com

I have a few questions here:

  1. is it for target milestone 4.3? Please, update.
  2. "references to TR-157" - That means an update of TR-069 PA Guideline, TR-069 Software Module Object mapping? If yes, we need more details: 2.1 Device.SoftwareModules.ExecutionUnit.{i}.References can points to: --- only one OSGi.{i}.BundleState.{i}. instance - the same bundle must represent ExecutionUnit and BundleState --- a few OSGi.{i}.ServiceState.{i}. instances - ExecutionUnit bundle must be the provider of all service instances --- a few OSGi.{i}.PackageState.{i}. instances - ExecutionUnit bundle must be exporter of all packages 2.2 How can link Device.SoftwareModules.ExecEnv.{i}. with OSGi.{i}.? There is no execution environment reference.

I think we are talking about adding additional parameters to the RFC-140 BBF data model, not about the existing References parameter in the TR-157 data model.

So I think that we will end up with OSGi.BundleState.{i} instances reference the corresponding TR-157 DU (?) instances, which reference any other application-specific data model objects that were created as a side-effect of the Bundle/DU installation.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

I have a few questions here:

  1. is it for target milestone 4.3? Please, update.
  2. "references to TR-157" - That means an update of TR-069 PA Guideline, TR-069 Software Module Object mapping? If yes, we need more details: 2.1 Device.SoftwareModules.ExecutionUnit.{i}.References can points to: --- only one OSGi.{i}.BundleState.{i}. instance - the same bundle must represent ExecutionUnit and BundleState --- a few OSGi.{i}.ServiceState.{i}. instances - ExecutionUnit bundle must be the provider of all service instances --- a few OSGi.{i}.PackageState.{i}. instances - ExecutionUnit bundle must be exporter of all packages 2.2 How can link Device.SoftwareModules.ExecEnv.{i}. with OSGi.{i}.? There is no execution environment reference.

I think we are talking about adding additional parameters to the RFC-140 BBF data model, not about the existing References parameter in the TR-157 data model. On the one hand, that means a new node in OSGi RMT. On the other hand, OSGi RMT should be protocol independent. I think that it's not a good idea to put that new node in OSGi RMT.

So I think that we will end up with OSGi.BundleState.{i} instances reference the corresponding TR-157 DU (?) instances, which reference any other application-specific data model objects that were created as a side-effect of the Bundle/DU installation. I am not sure that it's the best relation direction. Let me describe in more detail. Two possible scenarios are available:

  1. from common to specific - that means TR-157 reference to BBF RMT data model
  2. from specific to common - that means BBF RMT reference to TR-157 data model I like the first approach because, the management server can operate over DU/EU. If it needs more details, it can get the reference to BBF RMT and collect the details.
bjhargrave commented 13 years ago

Comment author: william.lupton@pace.com

I think we are talking about adding additional parameters to the RFC-140 BBF data model, not about the existing References parameter in the TR-157 data model. On the one hand, that means a new node in OSGi RMT. On the other hand, OSGi RMT should be protocol independent. I think that it's not a good idea to put that new node in OSGi RMT.

I agree that the data model should be protocol independent. See continued discussion below.

I was trying to make a more general point here. The TR-157 References parameter "Represents the instances of multi-instanced objects that are directly controlled by, and have come into existence because of, this ExecutionUnit. See [Appendix II.3.2/TR-157a3] for more description and some examples".

Therefore I don't believe that it was ever intended that the References parameter should reference an EE FRAMEWORK entity such as an OSGi.{i}.BundleState instance (the Device.SoftwareModules.ExecutionUnit.{i} instance came into existence because of the OSGi bundle, not the other way round). I think that it is intended to reference an APPLICATION entity.

For example (using the example that I used in the face-to-face last week) if the bundle implements a web server then a new instance of a Device.WebServer.{i} table might be created when it is installed, in which case References might reference this new WebServer.{i} instance.

But I agree that it would be POSSIBLE to use the References parameter for the purpose that you suggest.

So I think that we will end up with OSGi.BundleState.{i} instances reference the corresponding TR-157 DU (?) instances, which reference any other application-specific data model objects that were created as a side-effect of the Bundle/DU installation. I am not sure that it's the best relation direction. Let me describe in more detail. Two possible scenarios are available:

  1. from common to specific - that means TR-157 reference to BBF RMT data model
  2. from specific to common - that means BBF RMT reference to TR-157 data model I like the first approach because, the management server can operate over DU/EU. If it needs more details, it can get the reference to BBF RMT and collect the details.

I think that a common object should not know about a specific object. There is an OO analogy: derived classes know about base classes but not vice versa.

So I think that from a data model design point of view it is better for the (specific) OSGi.BundleState.{i} instance to reference the (common) SoftwareModules.ExecutionUnit.{i} (or DeploymentUnit.{i}?) instance.

I take your point that we don't want the RMT to be protocol-specific. So this suggests that we either (a) include such a parameter in the RMT but with a protocol-independent definition, or (b) omit such a parameter from the RMT and make it the responsibility of the PA.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

I think we are talking about adding additional parameters to the RFC-140 BBF data model, not about the existing References parameter in the TR-157 data model. On the one hand, that means a new node in OSGi RMT. On the other hand, OSGi RMT should be protocol independent. I think that it's not a good idea to put that new node in OSGi RMT.

I agree that the data model should be protocol independent. See continued discussion below.

I was trying to make a more general point here. The TR-157 References parameter "Represents the instances of multi-instanced objects that are directly controlled by, and have come into existence because of, this ExecutionUnit. See [Appendix II.3.2/TR-157a3] for more description and some examples".

Therefore I don't believe that it was ever intended that the References parameter should reference an EE FRAMEWORK entity such as an OSGi.{i}.BundleState instance (the Device.SoftwareModules.ExecutionUnit.{i} instance came into existence because of the OSGi bundle, not the other way round). I think that it is intended to reference an APPLICATION entity.

For example (using the example that I used in the face-to-face last week) if the bundle implements a web server then a new instance of a Device.WebServer.{i} table might be created when it is installed, in which case References might reference this new WebServer.{i} instance.

But I agree that it would be POSSIBLE to use the References parameter for the purpose that you suggest. Ok, it's possible solution.

So I think that we will end up with OSGi.BundleState.{i} instances reference the corresponding TR-157 DU (?) instances, which reference any other application-specific data model objects that were created as a side-effect of the Bundle/DU installation. I am not sure that it's the best relation direction. Let me describe in more detail. Two possible scenarios are available:

  1. from common to specific - that means TR-157 reference to BBF RMT data model
  2. from specific to common - that means BBF RMT reference to TR-157 data model I like the first approach because, the management server can operate over DU/EU. If it needs more details, it can get the reference to BBF RMT and collect the details.

I think that a common object should not know about a specific object. There is an OO analogy: derived classes know about base classes but not vice versa. The relation is different and TR-157 References parameter does that.

So I think that from a data model design point of view it is better for the (specific) OSGi.BundleState.{i} instance to reference the (common) SoftwareModules.ExecutionUnit.{i} (or DeploymentUnit.{i}?) instance.

I take your point that we don't want the RMT to be protocol-specific. So this suggests that we either (a) include such a parameter in the RMT but with a protocol-independent definition, Protocol-independent definition doesn't provide a solution. It moves the dependency from spec doc to runtime. or (b) omit such a parameter from the RMT and make it the responsibility of the PA. PA doesn't know about the specific data models. So, it cannot provide relations.

NTT, DT, Hitachi,... can you check and comment that issue?

bjhargrave commented 13 years ago

Comment author: hkirksey@motive.com

Note that we have some TR-069 protocol specific parameters in the TR-069 XML data model that are in addition to RFC 140, such as the Alias parameters. I think perhaps what would be best is not to worry about updating RFC 140 as such, but to include the TR-069 specific references (and these are distinct from the existing "References" parameter in TR-157, which was intended for a different use) in the TR-069 XML document. That seems like the cleanest option and inline with what we have done for those other TR-069 concepts.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

The comment: https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1970#c12 points that implicitly we have references between TR-157 data model and OSGi data model. It is in format EUID = DUID = BundleStateID.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Note that we have some TR-069 protocol specific parameters in the TR-069 XML data model that are in addition to RFC 140, such as the Alias parameters. I think perhaps what would be best is not to worry about updating RFC 140 as such, but to include the TR-069 specific references (and these are distinct from the existing "References" parameter in TR-157, which was intended for a different use) in the TR-069 XML document. That seems like the cleanest option and inline with what we have done for those other TR-069 concepts. OSGi represents a specification of real software unit. Some TR specific parameters were discussed and integrated. Alias parameters can be implemented according to: https://www.osgi.org/members/svn/documents/trunk/eg/reg/draft%20specifications/REG-spec-TR-069ProtocolImplementationGuideline.odt, section Alias Parameter Support NumberOfEntries parameters can be implemented according to: same document, section Number of Entries Support. So, if REG wants to support something new, REG needs to decide how can be supported. It is not just an abstract text description.

bjhargrave commented 13 years ago

Comment author: william.lupton@pace.com

The comment: https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1970#c12 points that implicitly we have references between TR-157 data model and OSGi data model. It is in format EUID = DUID = BundleStateID.

the referenced comment actually QUESTIONS whether that relation is guaranteed to be correct (by asking whether the implementation can choose to associate a DU with, for example, a deployment package rather than a bundle)

bjhargrave commented 13 years ago

Comment author: william.lupton@pace.com

The comment: https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1970#c12 points that implicitly we have references between TR-157 data model and OSGi data model. It is in format EUID = DUID = BundleStateID.

the referenced comment actually QUESTIONS whether that relation is guaranteed to be correct (by asking whether the implementation can choose to associate a DU with, for example, a deployment package rather than a bundle)

i hadn't read bug BZ#1970 comment BZ#13 when i wrote the above; it says:

Good point. But can we be sure that these are always the same or is there some implementation freedom, e.g. to map deployment packages (is that the right term?) to DUs? If the implementation follows the OSGi specification, there is no freedom about that. I known that the mapping is a part of the guideline: https://www.osgi.org/members/svn/documents/trunk/eg/reg/draft%20specifications/REG-spec-TR-069ProtocolImplementationGuideline.odt, section TR-069 Software Module Object mapping, but it's OSGi recommendation and can ensure the expected identifiers.

this is a recommendation, not a requirement, is that right? or are all the implementation guidelines effectively requirements?

to come back to the original issue, i definitely think that we do NOT want to use the References parameter for this purpose (this view is supported by Heather in comment BZ#6); if we feel that these references are already adequately covered by (a) the definitions of EUID, DUID and ID in the respective data model definitions, and (b) the TR-069 implementation guidelines, then I am OK with that

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

The comment: https://www.osgi.org/members/bugzilla/show_bug.cgi?id=1970#c12 points that implicitly we have references between TR-157 data model and OSGi data model. It is in format EUID = DUID = BundleStateID.

the referenced comment actually QUESTIONS whether that relation is guaranteed to be correct (by asking whether the implementation can choose to associate a DU with, for example, a deployment package rather than a bundle)

i hadn't read bug BZ#1970 comment BZ#13 when i wrote the above; it says:

Good point. But can we be sure that these are always the same or is there some implementation freedom, e.g. to map deployment packages (is that the right term?) to DUs? If the implementation follows the OSGi specification, there is no freedom about that. I known that the mapping is a part of the guideline: https://www.osgi.org/members/svn/documents/trunk/eg/reg/draft%20specifications/REG-spec-TR-069ProtocolImplementationGuideline.odt, section TR-069 Software Module Object mapping, but it's OSGi recommendation and can ensure the expected identifiers.

this is a recommendation, not a requirement, is that right? It's a part of TR-069 PA guideline. So, I believe that this is only a recommendation. or are all the implementation guidelines effectively requirements? The guideline is not mandatory. The implementation is free to follow another approach, but must be careful. All recommendations are not accidental.

to come back to the original issue, i definitely think that we do NOT want to use the References parameter for this purpose (this view is supported by Heather in comment BZ#6); I agree, References should not point to another representation of EU. if we feel that these references are already adequately covered by (a) the definitions of EUID, DUID and ID in the respective data model definitions, and (b) the TR-069 implementation guidelines, then I am OK with that

It's fine to me too.

Hitachi, NTT, DT can you check and comment that?

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

[11.05.2011] REG Conference Call Software Module Management mapping will be updated to make clear the positives and negatives.

bjhargrave commented 13 years ago

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

I tried to clarify that in the last doc update. Please, check it! If there are some issues, just reopen the issue.