Re: [Architecture] NextGen Tooling - Tool Palette

[Imesh Gunaratne]

Hi Frank,

On Sun, Sep 4, 2016 at 4:06 PM, Frank Leymann  wrote:

> Hi Imesh,
>
> please allow for a question:  if I draw a diagram, I control the layout if
> it and as long as I don't store it I can chance the size of the elements
> etc - is that correct?  But once I filed it, I can no longer change the
> sizes and I can't change the position of the elements?  Why not, i.e. what
> is the technical problem behind it?
>

​What we thought at the initial design meeting was, not to allow the user
to position and re-size elements. Anyway I agree that it's a vital
requirement of a diagramming tool. Let's discuss and see how we can support
this.

>
> I just tried in Camunda editor:  I can change everything and save, open
> and change everything and save, open.  and the changes are all
> preserved as I made them.   Same is true for Signavio editor (tested just a
> minute ago too).
>
> What the tools are doing is, that the corresponding .bpmn filel has two
> subdocuments: one subdocument contains all the model elements to represent
> the process MODEL (in the  element), and then the rendering
> information for each model element including x-y-coordinates, height, width
> etc (in the  element).
>
> Thus, it state of the art to preserve the layouting information. I.e. we
> shouldn't be weaker than the state of the art.  Finally, you don't need to
> introduce a second file but can maintain the layouting info in the same
> file - but cleanly separate between the logic of the process model and its
> layout info.
>

Thanks for pointing this out! I think this would work very well for
diagrams which users would always use the tool to define the workflow.
However for diagrams which users would prefer to directly write the
language syntax, storing metadata on the same file may cause redability
issues.

How do you like the approach MySQL Workbench has taken for storing EER
diagrams? Those diagram files store both the language definition and
diagram metadata. When needed language definition can be generated from the
diagram file. If the database structure is first created, the diagram file
can be auto generated.

Thanks

>
>
> Best regards,
> Frank
>
> 2016-09-04 4:31 GMT+02:00 Imesh Gunaratne :
>
>> Hi Frank,
>>
>> On Sat, Sep 3, 2016 at 8:35 PM, Frank Leymann  wrote:
>>
>>> Let me even emphasize what Chathura wrote: users will be really annoyed
>>> if we don't preserve the layout/rendering of a diagram. It will be a
>>> show-stopper for using the tool
>>>
>>
>> Thanks for your feedback! According to the current approach the layout
>> and rendering of the diagram will be preserved. The tool will render
>> diagrams the same way as the author drew it, for any other user. The only
>> limitation user will experience is that, re-positioning and re-sizing of
>> the elements will not be possible, those will be controlled by the tool.
>>
>> If we were to persist positioning and sizing information, we might need
>> to introduce a diagram file inaddition to the language file. Do you think
>> we need to follow that model?
>>
>> Thanks
>>
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2016-08-31 6:01 GMT+02:00 Chathura Ekanayake :
>>>
 Hi Susinda / Imesh,

 If positioning information is not stored with the diagram, does it auto
 adjust size and positioning of elements based on the length of text
 provided as lifeline labels and text on lines connecting lifelines?
 Further, are we allowing users to change the order of lifelines?

 I think, although we might not need for sequence diagrams, in general
 it may be better to store positioning information with diagrams as auto
 layouting can be a complex problem. In addition, users may feel lack of
 control over the diagram, if they cannot position elements. For example,
 BPMN stores positioning information for each task and sequence in a
 separate xml section, which is referred by the corresponding logical
 construct when drawing the diagram in a canvas.

 Regards,
 Chathura

 On Tue, Aug 30, 2016 at 4:24 PM, Susinda Perera 
 wrote:

> Hi Imesh
>
> +1 for all other suggestions and comments
> Multiple groups added only to demonstrate the tool-palette features,
> not needed for this editor but may be useful for datamapper editor.
> We need to finalize the icons for the various tools/actions - Hope ESb
> team can give some input
> We will have UX review fix the other UI issues, +1 for go with a theme
> approach (like dark/white)
> I'll do the code refactoring for the name changes and positioning
> issues.
>
> Thanks
> Susinda
>
>
> On Tue, Aug 30, 2016 at 3:35 PM, Imesh Gunaratne 
> wrote:
>
>> Great work Susinda! Few comments below:
>>
>>- I think initially we may not need multiple groups inside the
>>tool 

Re: [Architecture] OSGI Service to provision users and roles based on the SAML response.

[Dimuthu Leelarathne]

Hi Ishara,

On Fri, Sep 2, 2016 at 11:19 AM, Ishara Cooray  wrote:

> Hi All,
>
> I thought of introducing a new Authenticator config to
> repository/conf/security/authenticators.xml
> And it will use only below properties to do the $Subject.
>
> 
> 9
> 
> http
> ://wso2.org/claims/role
> ,
> true
> PRIMARY
> 
> 
>
> Any objections?
>

I think the existing SAMLSSOAuthenticator should allow JIT provisioning
when we switch on a configuration. If we keep adding more and more
Authenticators for small functionalities it will be cluttered collection in
the end. The same happened to Carbon components. We have so many components
and can't make the head or tail out of it.

thanks,
Dimuthu


> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Aug 31, 2016 at 1:43 PM, Ishara Cooray  wrote:
>
>> + Prabath, Johann
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Wed, Aug 31, 2016 at 1:27 PM, Pamod Sylvester  wrote:
>>
>>> Would it make sense to have it under "user-mgt.xml" ?
>>>
>>> On Wed, Aug 31, 2016 at 1:00 PM, Ishara Cooray  wrote:
>>>
 Hi,
 I am working on the $Subject.

 *Motivation:*
 I have a use case where i want to authorize users who are logged into
 API publisher/ store but APIM does not have the access to underline user
 store.

 *Plan:*
 The plan is to write an osgi service that should do the Just In Time
 provisioning before the permission check to authorize the user. And it will
 get the roles from the SAML response and do the provisioning.

 But we will have to do the same role/permission mapping manually for
 now.

 If we write a generic service  we can plug it into any wso2 product
 that need JIT provision initiated by the Service provider.
 However we need to maintain few configurations here.

1. isServiceProvierInitiatedJITProvisioningEnabled
2. User store to be provisioned
3. Implementation class (extension point)

 What could be the best place to maintain this configuration if the
 component is written as a generic component to any wso2 product?


 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> *Pamod Sylvester *
>>>
>>> *WSO2 Inc.; http://wso2.com *
>>> cell: +94 77 7779495
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Dimuthu Leelarathne
Director, Solutions Architecture

WSO2, Inc. (http://wso2.com)
email: dimut...@wso2.com
Mobile: +94773661935
Blog: http://muthulee.blogspot.com

Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] NextGen Tooling - Tool Palette

[Frank Leymann]

Hi Imesh,

please allow for a question:  if I draw a diagram, I control the layout if
it and as long as I don't store it I can chance the size of the elements
etc - is that correct?  But once I filed it, I can no longer change the
sizes and I can't change the position of the elements?  Why not, i.e. what
is the technical problem behind it?

I just tried in Camunda editor:  I can change everything and save, open and
change everything and save, open.  and the changes are all preserved as
I made them.   Same is true for Signavio editor (tested just a minute ago
too).

What the tools are doing is, that the corresponding .bpmn filel has two
subdocuments: one subdocument contains all the model elements to represent
the process MODEL (in the  element), and then the rendering
information for each model element including x-y-coordinates, height, width
etc (in the  element).

Thus, it state of the art to preserve the layouting information. I.e. we
shouldn't be weaker than the state of the art.  Finally, you don't need to
introduce a second file but can maintain the layouting info in the same
file - but cleanly separate between the logic of the process model and its
layout info.


Best regards,
Frank

2016-09-04 4:31 GMT+02:00 Imesh Gunaratne :

> Hi Frank,
>
> On Sat, Sep 3, 2016 at 8:35 PM, Frank Leymann  wrote:
>
>> Let me even emphasize what Chathura wrote: users will be really annoyed
>> if we don't preserve the layout/rendering of a diagram. It will be a
>> show-stopper for using the tool
>>
>
> Thanks for your feedback! According to the current approach the layout and
> rendering of the diagram will be preserved. The tool will render diagrams
> the same way as the author drew it, for any other user. The only limitation
> user will experience is that, re-positioning and re-sizing of the elements
> will not be possible, those will be controlled by the tool.
>
> If we were to persist positioning and sizing information, we might need to
> introduce a diagram file inaddition to the language file. Do you think we
> need to follow that model?
>
> Thanks
>
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-08-31 6:01 GMT+02:00 Chathura Ekanayake :
>>
>>> Hi Susinda / Imesh,
>>>
>>> If positioning information is not stored with the diagram, does it auto
>>> adjust size and positioning of elements based on the length of text
>>> provided as lifeline labels and text on lines connecting lifelines?
>>> Further, are we allowing users to change the order of lifelines?
>>>
>>> I think, although we might not need for sequence diagrams, in general it
>>> may be better to store positioning information with diagrams as auto
>>> layouting can be a complex problem. In addition, users may feel lack of
>>> control over the diagram, if they cannot position elements. For example,
>>> BPMN stores positioning information for each task and sequence in a
>>> separate xml section, which is referred by the corresponding logical
>>> construct when drawing the diagram in a canvas.
>>>
>>> Regards,
>>> Chathura
>>>
>>> On Tue, Aug 30, 2016 at 4:24 PM, Susinda Perera 
>>> wrote:
>>>
 Hi Imesh

 +1 for all other suggestions and comments
 Multiple groups added only to demonstrate the tool-palette features,
 not needed for this editor but may be useful for datamapper editor.
 We need to finalize the icons for the various tools/actions - Hope ESb
 team can give some input
 We will have UX review fix the other UI issues, +1 for go with a theme
 approach (like dark/white)
 I'll do the code refactoring for the name changes and positioning
 issues.

 Thanks
 Susinda


 On Tue, Aug 30, 2016 at 3:35 PM, Imesh Gunaratne 
 wrote:

> Great work Susinda! Few comments below:
>
>- I think initially we may not need multiple groups inside the
>tool palette for sequence diagramming module.
>- Maybe we can directly use the exact tool palette elements we
>need; Lifecycles, Mediators, and Arrows.
>- The term Tool used at Tools.Models.Tool, might not suit well.
>Shall we call it an Element/Item (a tool palette element/item)?
>- The images used inside the tool palette may need to have
>transparent backgrounds.
>- Overall, we may also need to consider following:
>   - As we do not store positioning data, we may need to do the
>   positioning for the user. If so we may not need to provide user to 
> change
>   the positioning of elements as needed.
>   - We might need to update the colours of the elements and the
>   tool palette according to a colour scheme.
>
> Thanks
>
>
> On Tue, Aug 30, 2016 at 1:04 PM, Susinda Perera 
> wrote:
>
>> The same webpage can be seen at here[1]
>> [1] -