[jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-139) Create a general purpose group RPC API

[Brian Stansberry (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBCLUSTER-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12528565#action_12528565 ] 

Brian Stansberry commented on JBCLUSTER-139:
--------------------------------------------

Creating 4 new interfaces:

GroupCommunicationService:  super-interface to the other 3 with common core methods
GroupRpcDispatcher: RPC methods
GroupMembershipNotifier/Listener: membership change notifications
GroupStateTransferService: API for JBAS-3594

HAPartition will extend the latter 3.

> Create a general purpose group RPC API
> --------------------------------------
>
>                 Key: JBCLUSTER-139
>                 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-139
>             Project: JBoss Clustering
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-API
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: HA-Server-API 2.0.0.Beta1
>
>
> Abstraction on top of JGroups RpcDispatcher.
> Start with HAPartition as a base, but minus DRM and DS.  Consider what Messaging has done as well as JBCACHE-311.
> Consider separating the group membership API from the RPC API. RPC API would probably be a subinterface of the group membership one, as group RPC implies being aware of who the group is.
> This is lower priority, as, except for AS, its an internal implementation detail that can be changed.  But, AS exposes HAPartition as an API for end-user code.

-- 
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