The way to put all these different data models under a single umbrella is
to create a UML <https://en.wikipedia.org/wiki/Unified_Modeling_Language>
Information Model using Eclipse/Papyrus (as an open source tool).
Unified Modeling Language (UML) is a standard syntax for describing the
architectural design of a system

   - Object Management Group (OMG) & ISO standard
   - Originated from object-oriented software development methods

UML includes many diagrams types to graphically represent parts of a
system?s model, including

   - Structural Views: The static nature of the system using objects,
   attributes and relationships (e.g., information or components that must be
   present in the system). This includes class diagrams and component diagrams.
   - Behavioral: The dynamic nature of the system through collaboration of
   objects and state changes (e.g., activities performed by the system). This
   includes use case diagrams, sequence diagrams, state machines.

UML is protocol agnostic and therefore these "Information Models" are
protocol agnostic.

UML models can then be transformed into protocol specific data models such
as YANG, XML, SMIv2, etc.

Creating a UML Information Model allows data cohesion across the various
interfaces in the system.  Using Interface Realizations
<http://www.uml-diagrams.org/realization.html>, specific interfaces can be
modeled.  In fact, an interface Information Model could be transformed into
multiple data models to support multiple management protocols.

Therefore, the focus first is on building a UML Information Model, then
once that's approved by the organization, then data models and encodings
can be generated based on the chosen interface protocols.

Thanks,
Brian

On Sun, Apr 23, 2017 at 5:13 AM, <zhao.huabing at zte.com.cn> wrote:

> Hi Brijesh,
>
> You brought up a great topic, we may need to converge at the same aspect,
> but for different aspects, there are different modelling languages which
> can better meet the specific requirement of that aspect, and they are very
> complementary.
>
> For example, TOSCA(Heat is another, come with openstack) is a good choice
> for the topology modelling of cloud application , YANG can be used for the
> configuration model( normally using for L2 L3, can be used for L4-L7 as
> well), and BPMN is good at workflow orchestration.
>
> It's difficult to put all these different modelling capabilities in a
> single data model or using an unique DSL, and we don't need to. But It's
> possible to make them work together smoothly under a unified umbrella
> system to accomplish the automated close loop and I'm glad to see ONAP has
> already make a very good start at that job.
>
> Thanks,
> Huabing
>
> ????
> *???:* BrijeshKhandelwal;
> *???:*GILBERT, MAZIN E (MAZIN E); denghui (L); JANA,RITTWIK (RITTWIK);
> onap-discuss at lists.onap.org; onap-tsc at lists.onap.org;
> *??:* 2017-04-22 11:56:56
> *??:Re: [onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th*
>
> Greetings,
>
>
>
> Adding some thoughts on information model:
>
> Orchestration need to interoperate among different interfaces, which in
> turn need to deal with very different payloads in form of YAML, YANG, JSON
>  etc. There will be lots of data processing among these models to process
> complete service. Handling these templates in orchestrator will impose
> limitations on capability and performance of orchestrator.
>
> So, there should have standardized data model for smooth processing among
> orchestration steps.
>
>
>
> Probably first time, orchestration is composing 3 different worlds of
> Network, Infra, IT, with different tunes of YANG, YAML, JSON/XML.
>
> Is there a play to develop standardized data models for orchestration,
> which will meet needs of each area? Is TOSCA sufficient? Or need some
> extended JSON data models?
>
>
>
>
>
> -Brijesh
>
>
>
> *From:* onap-tsc-bounces at lists.onap.org [mailto:onap-tsc-bounces@
> lists.onap.org] *On Behalf Of *GILBERT, MAZIN E (MAZIN E)
> *Sent:* Thursday, April 20, 2017 8:30 AM
> *To:* denghui (L); JANA, RITTWIK (RITTWIK)
> *Cc:* onap-discuss at lists.onap.org; onap-tsc at lists.onap.org
> *Subject:* Re: [onap-tsc] Modelling discussion on Friday May 5th
>
>
>
> Rittwik, Deng,
>
>
>
> This is great. Thank you  for taking the lead.
>
>
>
> I realize the focus is on TOSCA and parsers. Wonderful!
>
> I want to take you one level higher to start by discussing
>
> what the framework look like for the information model. Perhaps  invite
> folks who have
>
> operational experience. Then start describing the differernt
>
> data models and how TOSCA plays a role in driving service chaining and
> micro services
>
> (like analytics, data collections, etc).
>
>
>
> It would be great if the outcome of this mini session to
>
> be a recommendation position/paper or a proposal for a project.
>
>
>
> Mazin
>
>
>
>
>
> On Apr 20, 2017, at 4:34 AM, denghui (L) <denghui12 at huawei.com> wrote:
>
>
>
> Hello all
>
>
>
> We are happy to let you know that we are hosting a modeling session on
> Friday, May 5th, AT&T Lab.
>
> 9:00-10:30 Shitao moderate: TOSCA NFV Profile
>
> 10:30-12:00 Rittwik moderate: AT&T Parser
>
> 13:30-16:00 DengHui moderate: Modelling & Opendeployment
>
>
>
> Please kindly help to let us know if you are interested in joining us, so
> that we can book a proper meeting room for our discussion
>
>
>
> Best regards,
>
>
>
> Rittwik & DENG Hui
>
> _______________________________________________
> ONAP-TSC mailing list
> ONAP-TSC at lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.
> onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=
> 2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y&m=HRoKLiOZCWLzl3Z-
> 00DLQIUCwCAWqQL50mUFHtfYXYA&s=731fuCUnXbuPSOGHEcVf4U29cHpOGP
> KmwevRHGAoeiY&e=
>
>
>
> ============================================================
> ================================================================
>
> Disclaimer:  This message and the information contained herein is
> proprietary and confidential and subject to the Tech Mahindra policy
> statement, you may review the policy at http://www.techmahindra.com/
> Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html
> internally within TechMahindra.
>
> ============================================================
> ================================================================
>
>
> _______________________________________________
> ONAP-TSC mailing list
> ONAP-TSC at lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc
>
>


-- 
Brian Hedstrom
Founder/CEO
OAM Technology Consulting LLC
oamtechnologyconsulting.com
brian.hedstrom at oamtechnologies.com
720-470-7091
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-discuss/attachments/20170424/55ea7fc9/attachment.html>

Reply via email to