Should the SOA UI be integrated into the AS7 console?

[eric.wittmann]

It seems to me that the JBoss AS7 console is a management console.  The SOA UI is intended to be an end-user interface. 

I believe the following are examples of different groups of end users who will need access to the SOA UI:

• SOA Developers
• SOA Architects
• SOA Testers
• Java Developers
• SOA Governance Experts

Some activities that users of the UI will be able to do:

• Browse (filter) the SOA repository_
• CRUD the SOA artifacts in the repo
• View dependency graphs for SOA artifacts
• Perform impact analysis

Given the above (small) context, do you think it's appropriate to integrate this new UI into the JBoss AS7 console?  Does it even make sense to consider?

[rhauch]

I don't think it's appropriate to integrate the SOA Governance functionality into the AS7 Console: because the set of users of each app are largely non-overlapping. Besides, the SOA Goverance UI should expose on the front page the most common things the users will want do: find artifacts and upload new artfiacts. (Perhaps another thing is to see a list of recent activity, something akin to sites that show Twitter streams or how JIRA shows recent activity.) The other activities you mention most like require starting from some existing artifacts that were already found. If the SOA Governance were included in the AS7 Console, then the governance functionality would be buried.

Perhaps it might suffice to provide a link (albeit not on the front page) from the SOA Governance UI to the AS7 Console? I'm not even sure that's neccessary or useful.

There may also be information that the AS 7 Console exposes that some SOA Governance workers might like to see: the queue of asynchronous governance-related jobs (e.g., non-trivial analyses), maybe statistics/activity/load, etc. But ideally these would be tailored in ways that are useful to the Governance workers. And even these are likely 2nd or 3rd tier features.

[rcernich]

Hey Eric,

Based on your analysis, I do not think it makes sense for those activities to be incorporated into the AS7 console.  That said, I'm guessing there may be some amount of overlap.  Some possible, nonorthoganal activities:

• Register/publish deployed endpoints - I deploy a SY service that implements a governed interface and want that reflected in the repository (may also be scoped: development, test, production).
• Modify/change referenced endponts - More of a management task, an administrator may need to change the endpoint of a referenced service (e.g. changing providers, etc.).

After writing those out, they seem pretty specific to administration, but I'm guessing you may want the ability to manage those in the repository directly as well.

I would also guess you may want to provide some sort of linkage between systems.  For example:

• In the admin console, View Dependency Graph might take you to the SOA repository page displaying a dependency graph for the selected service.
• In the SOA repository, Perform Impact Analysis (and View Dependency Graph) may include links back to the admin console where the services are deployed (or referenced).

Just some rough thoughts at this point.

Best,

Rob

[rhauch]

Based on your analysis, I do not think it makes sense for those activities to be incorporated into the AS7 console.  That said, I'm guessing there may be some amount of overlap.  Some possible, nonorthoganal activities:

• Register/publish deployed endpoints - I deploy a SY service that implements a governed interface and want that reflected in the repository (may also be scoped: development, test, production).
• Modify/change referenced endponts - More of a management task, an administrator may need to change the endpoint of a referenced service (e.g. changing providers, etc.).

After writing those out, they seem pretty specific to administration, but I'm guessing you may want the ability to manage those in the repository directly as well.

Great points, Rob.

I would also guess you may want to provide some sort of linkage between systems.  For example:

• In the admin console, View Dependency Graph might take you to the SOA repository page displaying a dependency graph for the selected service.
• In the SOA repository, Perform Impact Analysis (and View Dependency Graph) may include links back to the admin console where the services are deployed (or referenced).

In fact, it might even be nice to have ways to "Deploy" or "Undeploy" a given service (based upon whether it is already deployed to the local cluster).

However, that does raise a few interesting questions:

1. Will each SOA-P installation also include SOA Governance?
2. And if I have multiple SOA-P installations (each with SOA Governance functionality), do I have separate SOA Governance repositories or do they all somehow all act as a single governance repository?

In order, will a SOA Governance installation (presumably clustered) govern the artifacts for the enterprise's set of services?

Perhaps the knowledge about whether an artifact is deployed should not at all be tied only to the AS7 instance (or domain) into which it is installed. Instead, maybe the SOA Governance system should know about multiple AS7/SOA-P installations and remotely (or locally) interact with the admin API to discover deployments.

[rcernich]

Hey Randall,

Randall Hauch wrote:

However, that does raise a few interesting questions:

1. Will each SOA-P installation also include SOA Governance?
2. And if I have multiple SOA-P installations (each with SOA Governance functionality), do I have separate SOA Governance repositories or do they all somehow all act as a single governance repository?

In order, will a SOA Governance installation (presumably clustered) govern the artifacts for the enterprise's set of services?

Perhaps the knowledge about whether an artifact is deployed should not at all be tied only to the AS7 instance (or domain) into which it is installed. Instead, maybe the SOA Governance system should know about multiple AS7/SOA-P installations and remotely (or locally) interact with the admin API to discover deployments.

I suspect the runtime would configure details about any governance system (similar to what is done today for UDDI, etc.).  At that point, the runtime can register itself so the governance system knows about it (if configured to do so).  (I also suspect the deployer would use this information to automatically register endpoints, etc., if configured to do so.)  I'm not sure how that might overlap with something like JON.

Talking about configuration, I'm guessing there some settings you'd configure that would govern (ouch ) how the runtime and repository interact with one another.

Best,

Rob

[eric.wittmann]

Thanks very much for the feedback, guys.  I also agree that it doesn't make sense to integrate the SOA UI with the AS7 console.  The SOA UI is its own application with its own usability requirements.  That said, I think you guys have hit upon some interesting integration points between a governance UI and the various systems being governed.  We'll need to be thoughtful about those integration points.