Ask Your Question
0

Quick question about SAL

asked 2014-05-28 12:08:13 -0700

anonymous user

Anonymous

Hi all,

I am new to ODL. Although I have read MD-SAL FAQ, Ping Example, Toaster step-by-step. However, I still cannot make up my mind which kind of SAL should I use when I design a new application. Can anyone tell me when do we use AD-SAL, when do we use MD-SAL? Take Topology Manager for example, why it makes use of both AD-SAL and MD-SAL?

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted
0

answered 2014-05-30 08:56:26 -0700

Devin Avery gravatar image

I am relatively new to the product, but here is my understanding of the history.


AD-SAL (API Driven Service Abstraction Layer?) was an original implementation, which provides a service layer. With AD-SAL plugins have to define custom northbound / southbound interactions and has to define all of the plumbing to move data in-between the two layers. If two services need to talk to each out you must manually fetch the services and perform the conversions to the correct data types for the given API your self. Additionally, consistency of north bound APIs etc must be manually maintained.

MD-SAL (Model Driven Service Abstraction Layer) is a more "recent" idea where we define a model which represents a logical entity. By using a standard model definition we can provide a standard set of capabilities and functionality that work for any model. For example, you get RESTCONF (north bound API) for free by simply defining a model (.yang file). Additionally, if you have two models that need to interact with either (think two different services) then you can use a common routing infrastructure to route the request. Ideally a model-driven design would separate business logic / model from the plumbing (the way you pass messages etc) making for easier and faster to use and understand services.


In terms of which to use.. well that is ultimately up to you and your project and what your needs currently are. The MD-SAL implementation provides (for better or for worse) auto code generation, a consistent (all-be-it slightly confusing) REST interface for all models, and handles a lot of the message routing / data storage etc for you.

Having not really used AD-SAL myself I can not comment on all of the benefits, but it is likely considered easier to use and more stable ( for now). Additionally the code path is pretty stright forward - you can easily trace from the REST call to implementation to the southbound side for example. But you have to generate the API, any documentation etc yourself, and manually ensure that you follow a consistent design.

General consensus in the community (at least from what I have seen) is that a Model Driven framework is a good idea, but we need to improve our implementation ("MD-SAL") before it will become really useable by most of the community (which we are really pushing to happen now).

If you are curious, check out these examples: https://wiki.opendaylight.org/view/Example_Code

edit flag offensive delete publish link more
Login/Signup to Answer

Question Tools

Follow
1 follower

Stats

Asked: 2014-05-28 12:08:13 -0700

Seen: 86 times

Last updated: May 30 '14