locked
MSRS compared with CORBA RRS feed

  • Question

  • I was wondering if anyone could comment on advantages/disadvantages on MSRS versus CORBA. Things like ease of use, complexity, execution speed/overhead, message through put, functionality, in what situations would you use one but not the other, etc.

     

    Any thoughts, information, experience, or partial experience is welcome,

     

    Thanks for any help,

     

    About us

    We are creating a system consisting of independent modules that run in parallel. Most likely they will all run on the same computer (multi core). We will be using C# and C++. We will be using it for automatic mail sorting machines, but we do not need to interact with hardware for this system (at this point).

    Tuesday, November 20, 2007 4:48 PM

Answers

  • Thomas,

     

    MSRS is quite different from CORBA and other distributed object systems such as DCOM or ILU for that matter at both the programming model as well as at the application level. It is hard to provide an exhaustive list of all the differences so let me instead explain a bit the MSRS model and provide links to additional information.

     

    The MSRS runtime consists of two parts that define the programming model and application model as follows (see Runtime Introduction for more details):

     

    Concurrency and Coordination Runtime (CCR) provides a highly concurrent, message oriented programming model with powerful orchestration primitives enabling coordination of messages without the use of manual threading, locks, semaphores, etc. CCR addresses the need of service-oriented applications by providing a programming model that facilitates managing asynchronous operations, dealing with concurrency, exploiting parallel hardware and handling partial failure. It enables you to design your application so that its software modules or components can be loosely coupled; that is, so that they can be developed independently and make minimal assumptions about their runtime environment and other components. This approach changes how you think of programs from the beginning of the design process and facilitates dealing with concurrency, failure and isolation in a consistent way.

     

    Decentralized Software Services (DSS) provides a lightweight, service oriented application model that combines key aspects of traditional Web-based architecture (commonly known as REST) with pieces of Web Services architecture. The application model defined by DSS builds on the REST model by exposing services through their state and a uniform set of operations over that state but extends the application model provided by HTTP by adding structured data manipulation, event notification, and service composition.

     

    The primary goal of DSS is to promote simplicity, interoperability, and loose coupling. This makes it particularly suited for creating applications as compositions of services regardless of whether these services are running within the same node or across the network. The result is a highly flexible yet simple platform for writing a broad set of applications. DSS uses HTTP and DSSP as the foundation for interacting with services. DSSP is a lightweight SOAP-based protocol that provides support for manipulation of structured state and for an event model driven by changes to the structured state. DSSP is used for manipulating and subscribing to services and hence compliments HTTP in providing a simple, state-driven application model.

     

    In MSRS a service is the basic computational unit that we use to abstract anything ranging from hardware to software to UI, mash-ups, etc. (see DSS Service Components for additional information). A service is a living document with a uniform set of operations that is composed with other services to form one or more applications. The service model separates state (which is public) from behavior (which is private) which is very different from a traditional data-hiding model. The benefits of the service model include:

    1. Responsiveness by facilitating orchestration of asynchronous messages

    2. Robustness by providing strong isolation between services, even in the same process, through no shared memory and no shared execution context.

    3. Loosely coupling by supporting dynamic discovery, creation, termination, and restart of services at runtime.

    4. Flexible UI which can be driven by the state of a service (or services) independently of the service implementation.

    In addition, the state of every service can be monitored through simple means like a Web browser providing a highly inspectable model that facilitates monitoring and debugging. We have several videos explaining the runtime and the application model as well as a chat with Jon Udell on the RESTful application model that explains the properties of our model in more detail.

     

    I hope this provides an idea of the MSRS model. For more information we have some additional links:

    1. Licensing information and Download information

    2. Various overviews of MSRS runtime, Application Model, Visual Programming Language (VPL), and Simulation Environment

    3. Documentation for MSRS in general including user guides for CCR and DSS

    4. MSRS community information with detailed use cases, scientific articles, partner technology releases etc. One example is this performance evaluation of CCR and DSS by Xiaohong Qiu and Geoffrey Fox from University of Indiana: “High Performance Multi-Paradigm Messaging Run Time on Multicore Systems”.

    Henrik

    Wednesday, November 21, 2007 2:07 AM
  • The amount of complexity of course depends on what you are going to do and your assumptions of how stable the operating environment is. Generally speaking, the less you expect from the environment in terms of synchronicity and reliability, the more complex distributed object-based solutions such as CORBA get.

     

    What we think MSRS is particularly good at is dealing with the increased complexity of concurrent and distributed systems. This is of course the situation not only in robotics but in many other areas as well which is why MSRS is being looked at in a range of non-robotics applications. The combination of the message-oriented programming model and the data-driven application model is very effective at handling orchestration of loosely coupled components operating in a concurrent and distributed environment where partial failure can happen at any point.

     

    Some of the benefits include:

     

    1)     Responsiveness due to high degree of asynchronicity

    2)     Robustness due to strong isolation with no shared memory or execution context between services (all messages are deep cloned and each service has its own task queue).

    3)     Loose coupling in that components are discovered, created, terminated, and restarted at runtime

     

    Furthermore, the model is highly scalable in that it allows you to not only scale up on a single node but also out across nodes using the same model. Performance wise it was a clear design goal to enable consistent use of service model for both local and distributed case.

     

    We do have a good performance comparison to traditional MPI solutions but not with CORBA. However, the numbers below may give you some guidance in how well MSRS performs (peak numbers on 4-core 2.4GHz, 4GB RAM):

     

    1)     Service-to-Service message throughput within same process (with full cloning):150K msgs/second

    2)     Service-to-service message throughout cross nodes, cross machine (encrypted): 6K msgs/sec

    3)     100K+ service instances per node

     

    Overall, while mileage varies for performance numbers, we have had good experience with the kind of applications that you can find on our community page and as an example of a non-robotics application, MySpace mentioned publically at Mix ’07 that they are using it as part of their infrastructure.

     

    Henrik

     

    Sunday, November 25, 2007 7:53 PM

All replies

  • Thomas,

     

    MSRS is quite different from CORBA and other distributed object systems such as DCOM or ILU for that matter at both the programming model as well as at the application level. It is hard to provide an exhaustive list of all the differences so let me instead explain a bit the MSRS model and provide links to additional information.

     

    The MSRS runtime consists of two parts that define the programming model and application model as follows (see Runtime Introduction for more details):

     

    Concurrency and Coordination Runtime (CCR) provides a highly concurrent, message oriented programming model with powerful orchestration primitives enabling coordination of messages without the use of manual threading, locks, semaphores, etc. CCR addresses the need of service-oriented applications by providing a programming model that facilitates managing asynchronous operations, dealing with concurrency, exploiting parallel hardware and handling partial failure. It enables you to design your application so that its software modules or components can be loosely coupled; that is, so that they can be developed independently and make minimal assumptions about their runtime environment and other components. This approach changes how you think of programs from the beginning of the design process and facilitates dealing with concurrency, failure and isolation in a consistent way.

     

    Decentralized Software Services (DSS) provides a lightweight, service oriented application model that combines key aspects of traditional Web-based architecture (commonly known as REST) with pieces of Web Services architecture. The application model defined by DSS builds on the REST model by exposing services through their state and a uniform set of operations over that state but extends the application model provided by HTTP by adding structured data manipulation, event notification, and service composition.

     

    The primary goal of DSS is to promote simplicity, interoperability, and loose coupling. This makes it particularly suited for creating applications as compositions of services regardless of whether these services are running within the same node or across the network. The result is a highly flexible yet simple platform for writing a broad set of applications. DSS uses HTTP and DSSP as the foundation for interacting with services. DSSP is a lightweight SOAP-based protocol that provides support for manipulation of structured state and for an event model driven by changes to the structured state. DSSP is used for manipulating and subscribing to services and hence compliments HTTP in providing a simple, state-driven application model.

     

    In MSRS a service is the basic computational unit that we use to abstract anything ranging from hardware to software to UI, mash-ups, etc. (see DSS Service Components for additional information). A service is a living document with a uniform set of operations that is composed with other services to form one or more applications. The service model separates state (which is public) from behavior (which is private) which is very different from a traditional data-hiding model. The benefits of the service model include:

    1. Responsiveness by facilitating orchestration of asynchronous messages

    2. Robustness by providing strong isolation between services, even in the same process, through no shared memory and no shared execution context.

    3. Loosely coupling by supporting dynamic discovery, creation, termination, and restart of services at runtime.

    4. Flexible UI which can be driven by the state of a service (or services) independently of the service implementation.

    In addition, the state of every service can be monitored through simple means like a Web browser providing a highly inspectable model that facilitates monitoring and debugging. We have several videos explaining the runtime and the application model as well as a chat with Jon Udell on the RESTful application model that explains the properties of our model in more detail.

     

    I hope this provides an idea of the MSRS model. For more information we have some additional links:

    1. Licensing information and Download information

    2. Various overviews of MSRS runtime, Application Model, Visual Programming Language (VPL), and Simulation Environment

    3. Documentation for MSRS in general including user guides for CCR and DSS

    4. MSRS community information with detailed use cases, scientific articles, partner technology releases etc. One example is this performance evaluation of CCR and DSS by Xiaohong Qiu and Geoffrey Fox from University of Indiana: “High Performance Multi-Paradigm Messaging Run Time on Multicore Systems”.

    Henrik

    Wednesday, November 21, 2007 2:07 AM
  • Thank you for all this useful information,

     

    It seems to me that Microsoft Robotics Studio is more "high level: than CORBA. We are trying to determine whether to use CORBA or Robotics Studio (among other frame works, JADE, JACK, Yarp, COM+) for coordinating communication between independent modules in a non-robotics application. We are also not very interested in monitoring the state of modules via browsers, but have nothing against this feature unless it adds a lot overhead.

     

    So some more specific questions,

     

    (1) How complex is Microsoft Robotics Studio programming compared to CORBA

     

    (2) How fast is Microsoft Robotics Studio compared to CORBA

     

    (3) Are there specific processes that Microsoft Robotics Studio simplifies for you compared to CORBA

     

    (4) Are there problems with CORBA or Microsoft Robotics Studio

    Wednesday, November 21, 2007 11:53 PM
  • The amount of complexity of course depends on what you are going to do and your assumptions of how stable the operating environment is. Generally speaking, the less you expect from the environment in terms of synchronicity and reliability, the more complex distributed object-based solutions such as CORBA get.

     

    What we think MSRS is particularly good at is dealing with the increased complexity of concurrent and distributed systems. This is of course the situation not only in robotics but in many other areas as well which is why MSRS is being looked at in a range of non-robotics applications. The combination of the message-oriented programming model and the data-driven application model is very effective at handling orchestration of loosely coupled components operating in a concurrent and distributed environment where partial failure can happen at any point.

     

    Some of the benefits include:

     

    1)     Responsiveness due to high degree of asynchronicity

    2)     Robustness due to strong isolation with no shared memory or execution context between services (all messages are deep cloned and each service has its own task queue).

    3)     Loose coupling in that components are discovered, created, terminated, and restarted at runtime

     

    Furthermore, the model is highly scalable in that it allows you to not only scale up on a single node but also out across nodes using the same model. Performance wise it was a clear design goal to enable consistent use of service model for both local and distributed case.

     

    We do have a good performance comparison to traditional MPI solutions but not with CORBA. However, the numbers below may give you some guidance in how well MSRS performs (peak numbers on 4-core 2.4GHz, 4GB RAM):

     

    1)     Service-to-Service message throughput within same process (with full cloning):150K msgs/second

    2)     Service-to-service message throughout cross nodes, cross machine (encrypted): 6K msgs/sec

    3)     100K+ service instances per node

     

    Overall, while mileage varies for performance numbers, we have had good experience with the kind of applications that you can find on our community page and as an example of a non-robotics application, MySpace mentioned publically at Mix ’07 that they are using it as part of their infrastructure.

     

    Henrik

     

    Sunday, November 25, 2007 7:53 PM
  • Thank you very much,

     

    This was a most helpful answer!

     

     

    Thomas Wikman

     

    Monday, November 26, 2007 2:16 AM