Hi Folks

Wrt to the following diagram from Tr-139

I'm currently working on the sdf metamodel.

I was wondering about the socket notation for Consumer and Resource Exposure.
In a traditional OO context the socket would imply that there is a corresponding ball notation for these two 'requireds' to couple with. (In UML the ball is an interface connected by a line or provided interface and the socket is a required interface .)

Having looked at TR139 I'm not sure this is explained what interface interacts with Consumer ? Should there be a Consumer provided as well?

(The diagram below implies SDF Service has 2 dependencies on somethings which aren't stated - ie the socket implies dependency)

Are we using the ball socket notation to mean the same thing as  UML?

Reason I'm asking is that I'm modelling this and need to have a clear understanding of what you expect or require!

If you are not sure, are you happy for me to use my skill and judgement to suggest something in the
metamodel?

regards
Steve

Steve, dependencies and the stereotypes on them are still under discussion as mentioned in TR-139.

Some background on how they came to being and this may invite more comments and/or ease your modeling task

1. why dependencies:

Most of this representation is inspired by the SOA based NGN OSS Service and its Interfaces in ETSI's reference model; that model represents both the Service Interface (lollipop) and the Service Interface Consumer (socket); the rationale behind representing Consumers was to indicate how/if an NGN OSS services uses  a NOSI published by another NGN OSS Service and I found also [in the TS-18880001 spec] a constraint saying that a Consumer that offers that same functionality must realize it through its own NOSIs.

The underlying SOA assumption of the model helps with establishing dynamic/runtime relationships between Interfaces and their Consumers  but sometimes it may go manual. Tracing how they happen  is important  for understanding dependencies, dimensioning/capacity planning.

This dependency tracing has been emphasized as very important for managing operational environments from change, revision, packaging, operational integrity perspectives.

It has been argued with good reasons that dependencies can sit in the metadata and that such "Consumer" dependency is not really needed on the model.  

2. the meaning of dependencies:

In SDF service model, Service Interfaces have been subtyped "Functional" and "LCM". Consumer interfaces have been subtyped using a little bit different rationale:

- dependency on legacy resources that have no SOA capabilities and can not be represented as SOA compliant service

- functional dependency in the approach described above, meaning on similarly defined services

Does this help?

 Lucia

 

Lucia

Thanks for this makes total sense - I can see how to progress

thanks
Steve

In my model, the SDF captures with the resource interface the dependencies on resources that are not modeled by SDF. Soyes these resources would have a function interface but when they are not modeled they are not shown, only captured with the interface to the resources that models / cares only ab out the fact that it has “adapters” to implement that interface (possibly different adapters to implement deployment against different product, network technologies etc... These may have LCM impact.Note as widely discussed in past and mentioned below by Lucia, I do not agree with having another dependency interface associated to a SDF.
 service /

component.  These interfaces exist in an implementation or deployment case  to model the flows between the elements but not as a definition of the component ? services. At the difference of the “adapters” the interface of dependencies are interfaces of other SDF components or resources.

See also my discussion in the mailing list and in the life cycle management section of Wiki. There I distinguish these notions as tangible dependencies not to confuse with untangible dependencies that are to be captured, expressed or modeled and managed with metadata not interfaces.

Eventually, even in a composition model, I would see a process composing the SDF services via their service interfaces rather than modeling it as a dependencies. I recommend people look carefully at the danger of such a view with dependencies. In fact then i think we should rather take the SCA path,,,

I hope this helps with you endeavor.

Wth respect to item 1:

With respect to dependencies and NOSI, as stated above i do not understand the model. Composition is through function interface. Packaging and reuse is better to follow SCA. Dependencies hosudl only model towrads resources external / not modeled by SDF... Untangible dependencies are not interface but to be captured in metadata...

With respect to bullet 2 / depenmdencieson legacy, I would rather state dependencies on resources not modeld by SDF. Nothing says they can't be represented in a SOA framework. In fact having SDF services abstracting them and exposing their function and life cycle managemnet interface is exactly the way to address that...

agree that resources not modeled in the SDF is a better description.

The latest TR139 v2 digram produced by Tanja De Groot is cleaning up some of these points. In my opinion the ball is an expeosed interface and the socket is a required  interface exactly as in UML. Agree wording at this stageis probaly incorrect.

 

---

Dave Milham
Customer Experience e2e Service Quality Management