Hi Frank, Please find my response inline.
On Mon, Feb 23, 2015 at 11:38 AM, Frank Leymann <[email protected]> wrote: > Senaka, > > multiple relatioships are fine: it doesn't occur very often, and if, more > than two relations are rare. > To start with I liked you thought from the beginning, but based on the experience during QSPs, Support Queries etc, people chase after these nitty gritty details, and we often spend most of the time fixing minor details like this. But, if we can handle it in some way (I think Jerad mentioned, you start minimalist and then you can turn colours on and off), I'm perfectly fine with that. > > And, yes, by all means, the ability to toggle particular collections of > relationship types on and off is extremely helpful! Similarly, the feature > that Isabelle brought up, namely specifying the level of children of a > certain node to view, will help comprehension... > > Who will detect policy violations (and: which kind of policies?)? If > policy violations are automatically detected, corresponding workflows might > be kicked-off to repair the violations. This will significantly contribute > to "compliance", an key aspect of governance. > Let me give you some examples of what I meant by Policy Violations. When you upload WSDL/WADL we automatically validate them againts WS-I, WSDL (i.e. standards compliance), and optionally a user can establish their own namespace checks, operation name validations etc. A standard property (or perhaps, quasi-standard to be precise) captures the valid/invalid state. We also can check whether a service exposes the kind of security you'd want it to, and also other similar kinds of policies. These again are recorded against the service as metadata. Another whole area is the lifecycle state, development vs QA vs prod. These again are standard properties. My view here was to annotate each of the nodes based on these properties such that they can be visualized as such in an impact graph, which will add a lot of meaning of what we see today. WRT compliance, I believe that's a separate thing, and I agree with you on its significance. We do have the capability to enforce compliance checks and also invoke external systems on failure as a part of the lifecycle management functionality. This is not fully automated though. But, the product does allow you to schedule tasks which can be utilised to achieve some level of automation. So, we do have a framework where we can start, but few things to be done and interfaces to be introduced for this to be useful. I believe that this is surely beyond 5.0.0. Thanks, Senaka. > > > Best regards, > Frank > > 2015-02-22 20:34 GMT+01:00 Senaka Fernando <[email protected]>: > >> Hi Frank, Jerad, >> >> Useful thought on colouring relationships. Frank, I have one question. >> What if multiple relationships coincide between two specific nodes, won't >> that complicate things? I have a feeling that turning relationships on and >> off (as in Jerad's GIF) is a way of visualizing how things connect and how >> deep. WDYT? >> >> Also, I have another question. Something I spoke about in WSO2Con US >> 2013, :), on G-Reg 5.0.0 was that you can use this view to understand >> lifecycle state, policy violations etc. Didn't see that part being >> addressed though. Jerad, given the things you've done so far, I don't >> expect this to be an impossible task, but how easy would it be to annotate >> nodes (using colours or miniature overlay graphics) to achieve this? >> >> Put together, these features alone will make G-Reg 10-times more usable >> that where it stands today in terms of Asset Governance. >> >> Thanks, >> Senaka. >> >> On Sun, Feb 22, 2015 at 5:00 PM, Frank Leymann <[email protected]> wrote: >> >>> HI Jerad, >>> >>> thanks, the gif was helpful :-) Very nice tool! >>> >>> Coloring nodes is optional (I would even argue: not needed). But >>> coloring relations will in fact improve comprehension of the user. See for >>> example when you select in your gif a subset of relationship types: it is >>> still unclear which relationship types connect the nodes. I would rank >>> relationship coloring much higher than node coloring. >>> >>> >>> >>> Best regards, >>> Frank >>> >>> 2015-02-21 6:31 GMT+01:00 Jerad Rutnam <[email protected]>: >>> >>>> Hi Frank, >>>> >>>> I get your point. Agree for giving users more flexible features. Yes, >>>> we were discussing about the coloring nodes, and this was decided to have >>>> like an optional feature. So it will be an enhance feature for filtering >>>> option. Which we decided to work on after releasing the tool. :) >>>> >>>> Please find the attached animated .gif image, that will give better >>>> idea about the tool functions. (Use chrome or better .gif previewer to open >>>> - since the file is large, it might not work on all the browsers correctly) >>>> >>>> Thanks, >>>> Jerad >>>> -- >>>> *Jerad Rutnam* >>>> *Software Engineer* >>>> >>>> WSO2 Inc. >>>> lean | enterprise | middleware >>>> M : +94 77 959 1609 | E : [email protected] | W : www.wso2.com >>>> >>> >>> >> >> >> -- >> >> >> *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* >> Solutions Architect; WSO2 Inc.; http://wso2.com >> >> >> >> *Member; Apache Software Foundation; http://apache.org >> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >> >> >> *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: >> http://linkedin.com/in/senakafernando >> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >> > > -- *[image: http://wso2.com] <http://wso2.com>Senaka Fernando* Solutions Architect; WSO2 Inc.; http://wso2.com *Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; *M: +44 782 741 1966 <%2B44%20782%20741%201966>Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
