[JBoss JIRA] Created: (SOAG-65) Blocking/waiting behaviour for WhenAction
by Gary Brown (JIRA)
Blocking/waiting behaviour for WhenAction
-----------------------------------------
Key: SOAG-65
URL: https://jira.jboss.org/jira/browse/SOAG-65
Project: SOA Governance
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Conversation Runtime
Reporter: Gary Brown
Assignee: Jeff Yu
Currently the WhenAction does immediate evaluation of an expression. This construct needs to enable blocking/waiting behaviour if the expression evaluates to false - using the services of an external mechanism that can monitor an expression, and re-evaluate it whenever a change occurs to the state for the session, and then trigger the appropriate service descriptor once the expression does evaluate to true.
The expression could also represent a timeout, and therefore this mechanism could be combined with the issue related to the WhenAction handling timeouts (SOAG-33).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (SOAG-97) Have CDL validation deployment lookup Service EPR
by Jeff DeLong (JIRA)
Have CDL validation deployment lookup Service EPR
-------------------------------------------------
Key: SOAG-97
URL: https://jira.jboss.org/jira/browse/SOAG-97
Project: SOA Governance
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: WS-CDL
Affects Versions: CONTINUING
Reporter: Jeff DeLong
Assignee: Mark Little
Instead of using annotations in the CDL model to add the ESB EPR to the service/participant for runtime validation purposes, perhaps as part of deployment into the server the deployer could use the service name to lookup the EPR, and then add this information to the validation configuration.
This would save the developer from having to copy runtime deployment information into the CDL files.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (SOAG-64) Deletion of grouping constructs
by Gary Brown (JIRA)
Deletion of grouping constructs
-------------------------------
Key: SOAG-64
URL: https://jira.jboss.org/jira/browse/SOAG-64
Project: SOA Governance
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Tooling
Affects Versions: 1.0 CR1
Reporter: Gary Brown
Assignee: Gary Brown
Currently, deletion of actions from the jboss-esb.xml file only occurs for simple activities (e.g. sends/receives and perform).
The problem with deleting grouping constructs is that, not only has the main construct got to be deleted, but the ESB service descriptors related to each path needs to be removed, potentially with further linked service descriptors.
In some cases, it will also be necessary to identify the 'join' service descriptor, and insert a ScheduleStateAction to transition to this service descriptor. Where the join service descriptor not explicitly defined in the grouping construct, it may possibly be inferred based on the following following action in the description - if one has been defined. Otherwise it may have to be inferred by examining each path, to determine where they converge.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (SOAG-106) Service activity event model
by Gary Brown (JIRA)
Service activity event model
----------------------------
Key: SOAG-106
URL: https://jira.jboss.org/jira/browse/SOAG-106
Project: SOA Governance
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Behavioural Monitoring
Affects Versions: 1.0 MR3
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 1.0 MR3
Definition of event model for reporting service activity from various runtime platforms, and storing the information in a repository.
Event model needs to be extensible, although there should be a fixed core of standard events defined.
The events could be interaction based, i.e. indicating messages being sent and received, or task based i.e. task started and finished. Data related events could also be stored, when variables are updated.
The actual events stored could be dependent upon filters defined in the activity recorders.
Question: should the event model be XML based? Or should it support message content being non-xml - i.e. Java objects, or other binary formats? Possible non-XML message contents could be reported in a summarised XML form, to provide enough useful information.
The events recorded from a service may be based on local service identity information. This can be used to group events generated by a particular session at a service, but they won't necessarily be business relevant. To be able to correlate service activity, associated with a particular business transaction, across multiple services, it will be necessary to derive business identity that is common across services. However, only some of the reported service activity events may contain the business identity properties - so these should be used to associate the business identity with the local technology specific service/session identity information.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[JBoss JIRA] Created: (SOAG-107) JBossESB service activity adapter
by Gary Brown (JIRA)
JBossESB service activity adapter
---------------------------------
Key: SOAG-107
URL: https://jira.jboss.org/jira/browse/SOAG-107
Project: SOA Governance
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Behavioural Monitoring
Affects Versions: 1.0 MR3
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 1.0 MR3
JBossESB 4.x service activity adapter for intercepting appropriate events and reporting them using the service activity event model.
Adapter should provide a filter mechanism that can be based on:
1) the message type - so only report certain event types
2) event type - only report certain event types
3) message content filter - to extract relevant information from the message content instead of sending the complete message, in situations where the data is too large
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years