"Kevin.Conner(a)jboss.com" wrote : Good, I'm glad that's clear :-)
|
| It may be that I have misunderstood the discussion but my concerns were the following
| - talk of defining the interface in SOAP and embedding in a servlet container
| - talk of clustering facades for non clustered implementations
|
| While both of these may be important from an implementation and deployment
perspective, neither is relevant to the service interface being defined.
|
| The priority for now is to work out the requirements for this interface and, while we
should keep the implementation details in mind, these details should not distract us from
the specification of the interface.
Agreed. Talking about SOAP and clustering is immediately taking us down the implementation
route. Although they are relevant to the topic (Registry Design), I think it would be
easier if we tried to keep each topic narrowly focussed. We already had a discussion
around the API,
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81236
where we agreed to use JAX-R.
We shouldn't be thinking about implementing a registry at this stage: believe me,
it'll take more time than we have available to us for the first GA. Plus, it's a
product/project in its own right (there are several companies whose sole reason to exist
is to sell a registry). Where I think we should be going with this is: given we'll use
JAX-R for now, what does that mean for the ESB? What JAX-R implementations are out there
that we can use? Do we have to implement our own JAX-R system (hopefully not). Assuming we
have JAX-R support, what existing registry implementations can be tied into it?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969415#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...