3 Replies Latest reply on Jan 13, 2011 8:36 AM by keplervic

    Savara 2: Scenarios

    objectiser

      In Savara 1, we use the pi4soa scenarios that are WS-CDL specific and require a direct reference to the CDM choreography file with which they are associated, to enable them to be simulated against that choreography.

       

      Savara 2 will also need to support BPMN2 as well as potentially other formats. Therefore we need to make the scenarios more independent of any business representation with which they will be compared against.

       

      The first thought was to maybe use the UML sequence model as the underlying format, however this will make the scenario XML files more complex, and they don't easily support the ability to store example messages. Using such a standard format may then conflict with standard UML modelling tools that won't provide an easy way to create or modify the savara scenarios.

       

      Therefore at the moment the preferred route is to create a Savara specific scenario representation that is simple, and have associated tools that understand how to deal with the information.

       

      Any objections?

        • 1. Savara 2: Scenarios
          bmadurai

          Hi Gary

           

          I completely concur with the approach that savara 2.0 should be more open and should allow for industry standard definitions like Bpmn. However,  I think we need to make roadmap very clear as your approach includes building on templates rather than generic uml. I would tend to think we could use open source uml editors ? Could that be an alternative to spending time creating a brand new savara toolsuite component?

          • 2. Savara 2: Scenarios
            objectiser

            That was the original thinking, that we should leverage a standard model (UML sequence diagrams) and tools. However there are two downsides with this:

             

            1) the UML sequence model has evolved from a simple mechanism for outlining a particular flow through a business process (a conversation instance), to being more like a type (i.e. repetition, branching, etc)

             

            2) the problem with using a standard representation is that a user's environment may be configured with their own preferred UML editor, and therefore we cannot predict how the additional information we would need to added to the model, through extensible elements, would be handled. It would make the user experience inconsistent across environments.

             

            When requiring something to perform a very specific task, it is sometimes better to have a new representation and tools that are tailored to the job, and thus make the user experience much better (and consistent) - don't forget we are aiming at business users, and although some of them may be familar with UML sequence diagrams, the fact that sequence models can have so many additional constructs that are not actually required, may lead to confusion.

             

            I am not saying UML sequence diagrams/models are not relevant - as with other representations we should be able to import/export.

            • 3. Savara 2: Scenarios
              keplervic

              Hi Gary

               

              I agree with your point (1) about the way Sequence Diagrams in UML have evolved. One of the two finalist consortia bidding to the OMG for the development of the UML2 standard stated in their submission that Sequence Diagrams have, in this very respect, unclear semantics and proposed a solution. Unfortunately, this consortium was not selected and the lack of clarity remains.

               

              Rgds

              Ashley