March 2013 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-156) Create Deriver for Switchyard content (switchyard.xml)

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/SRAMP-156?page=com.atlassian.jira.plugin.... ] Gary Brown commented on SRAMP-156: ---------------------------------- When creating the relationships between services within the same switchyard deployment, include metadata to indicate whether the invocation is local (inVM) or remote. Although external bindings should be based on the service interfaces, it would also be useful if users could query the service contracts to understand what bindings are supported (as there could be more than one). > Create Deriver for Switchyard content (switchyard.xml) > ------------------------------------------------------ > > Key: SRAMP-156 > URL: https://issues.jboss.org/browse/SRAMP-156 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.2.0 - Milestone 4 > > > Based on examples to be provided by Keith Babo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMPUI-62) Support a graphical view of the services and their relationships

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/SRAMPUI-62?page=com.atlassian.jira.plugin... ] Gary Brown commented on SRAMPUI-62: ----------------------------------- NOTE: This network/graph based representation could also form the basis of the static representation that underpins the 'service dependency' graph used in the runtime governance project, which currently is dynamic, based upon dynamic service interactions that have occurred within a configurable timeframe. Therefore when implementing this task, co-ordination with the runtime governance project should occur to ensure that the relevant common functionality can be factored out into share components - while at the same time not making either project dependent upon the other (e.g. at build, deployment or runtime). > Support a graphical view of the services and their relationships > ---------------------------------------------------------------- > > Key: SRAMPUI-62 > URL: https://issues.jboss.org/browse/SRAMPUI-62 > Project: S-RAMP UI > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Eric Wittmann > Fix For: Future (Unscheduled) > > > Currently a user can navigate the graph of services and their relationships. However this does not easily enable the user to understand the overall picture of how their services and dependencies may be structured. > A graphical view could help to better understand this information, enabling the user to navigate from the nodes or links to gain further information about the individual items. > In terms of the visual presentation, some UML diagrams may provide a familiar look. However this is just styling, and any network/graph based representation could be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMPUI-62) Support a graphical view of the services and their relationships

by Gary Brown (JIRA)

Gary Brown created SRAMPUI-62: --------------------------------- Summary: Support a graphical view of the services and their relationships Key: SRAMPUI-62 URL: https://issues.jboss.org/browse/SRAMPUI-62 Project: S-RAMP UI Issue Type: Feature Request Reporter: Gary Brown Assignee: Eric Wittmann Fix For: Future (Unscheduled) Currently a user can navigate the graph of services and their relationships. However this does not easily enable the user to understand the overall picture of how their services and dependencies may be structured. A graphical view could help to better understand this information, enabling the user to navigate from the nodes or links to gain further information about the individual items. In terms of the visual presentation, some UML diagrams may provide a familiar look. However this is just styling, and any network/graph based representation could be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-159) Auditing: provide a REST API for retrieving audit information

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/SRAMP-159?page=com.atlassian.jira.plugin.... ] Gary Brown commented on SRAMP-159: ---------------------------------- Can this task be extended to enable auditing data to be recorded through the REST API. Usecase: the governance workflow defines multiple approval steps before an artifact can be promoted into production. The actual audit change to the artifact, once that decision has been made, will potentially only be associated with the last person to approve the artifact, whereas for compliance purposes, it may be necessary for all people who approved the decision to be recorded in the audit logs. Therefore in straightforward cases we can rely on the actual modifications made to the artifacts in the repository to be enough of an audit. However in cases where this is not sufficient, we need the workflow to be able to explicitly add extra audit entries. > Auditing: provide a REST API for retrieving audit information > ------------------------------------------------------------- > > Key: SRAMP-159 > URL: https://issues.jboss.org/browse/SRAMP-159 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.2.0 - Milestone 4 > > > The REST API should provide a way to query for Audit data by artifact and by user. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-171) Enable WSLA artifacts to be associated with a service

by Gary Brown (JIRA)

Gary Brown created SRAMP-171: -------------------------------- Summary: Enable WSLA artifacts to be associated with a service Key: SRAMP-171 URL: https://issues.jboss.org/browse/SRAMP-171 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Kurt Stam Fix For: 0.2.0 - Milestone 4 WSLA will be used to represent the service level agreement properties related to response time and availability for a service. Therefore it should be possible to represent these documents in the repository and establish a relationship between them and the service contracts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-150) Obtain service availability information from external management systems

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-150?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-150: ----------------------------- Affects Version/s: (was: 1.0.0.M5) > Obtain service availability information from external management systems > ------------------------------------------------------------------------ > > Key: RTGOV-150 > URL: https://issues.jboss.org/browse/RTGOV-150 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > > For organizations that wish to perform more complex analysis of service availability, potentially in combination with other service related information (e.g. performance), it would be useful to have availability information supplied as events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-150) Obtain service availability information from external management systems

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-150?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-150: ----------------------------- Fix Version/s: 1.0.0.M5 > Obtain service availability information from external management systems > ------------------------------------------------------------------------ > > Key: RTGOV-150 > URL: https://issues.jboss.org/browse/RTGOV-150 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 1.0.0.M5 > > > For organizations that wish to perform more complex analysis of service availability, potentially in combination with other service related information (e.g. performance), it would be useful to have availability information supplied as events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-150) Obtain service availability information from external management systems

by Gary Brown (JIRA)

Gary Brown created RTGOV-150: -------------------------------- Summary: Obtain service availability information from external management systems Key: RTGOV-150 URL: https://issues.jboss.org/browse/RTGOV-150 Project: RTGov (Run Time Governance) Issue Type: Feature Request Affects Versions: 1.0.0.M5 Reporter: Gary Brown Assignee: Gary Brown For organizations that wish to perform more complex analysis of service availability, potentially in combination with other service related information (e.g. performance), it would be useful to have availability information supplied as events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-70) S-RAMP/WSLA to Event Processor Network generator

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-70?page=com.atlassian.jira.plugin.s... ] Gary Brown updated RTGOV-70: ---------------------------- Description: Generate an Event Processor Network to represent the Service Level Agreements (SLAs) defined within a S-RAMP repository. These agreements will be described using the WSLA standard. Initially only two properties will be considered, response time and availability. Availability information will need to be obtained from a management system. Under the control of a workflow, information provided within a WSLA definition associated with a service will be converted into an EPN. The EPN will then be treated as another deployable artifact along side the service it is monitoring. was: Generate an Event Processor Network to represent the Service policies (SLAs) defined within a S-RAMP repository. Decision will need to be made regarding how users will specify the policies within the repository. Too constrained and it may limit the flexibility of the SLAs, but unrestricted may make the specification and execution more complex. What should the source of events be? Response time or raw events leaving the generation process to include 'added value' nodes that derive some of the information that the policies may require? For the initial version it is probably better that the generated EPN only relies on the source activity events (or possibly filtered out SOA events), but then all further pre-processing must be done within the network itself. Users can then have some flexibility in what source events are available for the policies they write. > S-RAMP/WSLA to Event Processor Network generator > ------------------------------------------------ > > Key: RTGOV-70 > URL: https://issues.jboss.org/browse/RTGOV-70 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 1.1 > > > Generate an Event Processor Network to represent the Service Level Agreements (SLAs) defined within a S-RAMP repository. These agreements will be described using the WSLA standard. > Initially only two properties will be considered, response time and availability. > Availability information will need to be obtained from a management system. > Under the control of a workflow, information provided within a WSLA definition associated with a service will be converted into an EPN. The EPN will then be treated as another deployable artifact along side the service it is monitoring. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-70) S-RAMP/WSLA to Event Processor Network generator

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-70?page=com.atlassian.jira.plugin.s... ] Gary Brown updated RTGOV-70: ---------------------------- Summary: S-RAMP/WSLA to Event Processor Network generator (was: S-RAMP/Service Policy to Event Processor Network generator) > S-RAMP/WSLA to Event Processor Network generator > ------------------------------------------------ > > Key: RTGOV-70 > URL: https://issues.jboss.org/browse/RTGOV-70 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 1.1 > > > Generate an Event Processor Network to represent the Service policies (SLAs) defined within a S-RAMP repository. > Decision will need to be made regarding how users will specify the policies within the repository. Too constrained and it may limit the flexibility of the SLAs, but unrestricted may make the specification and execution more complex. > What should the source of events be? Response time or raw events leaving the generation process to include 'added value' nodes that derive some of the information that the policies may require? > For the initial version it is probably better that the generated EPN only relies on the source activity events (or possibly filtered out SOA events), but then all further pre-processing must be done within the network itself. > Users can then have some flexibility in what source events are available for the policies they write. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues March 2013