Novak, Miroslav wrote:
Hi,
 Thanks for your reply. I'm glad that you like the idea of "Service Discovery for 
SCA".

Actually, I think that the best (and probably simplest) interface for the 
discovery would be REST.

I'm nor SCA neither Tuscany expert so maybe that my view is too simplistic but 
I would like to use e.g. this URI space:


/domain/{an SCA domain}/composites/{a composite}/services
                                                /references
                       /composites/{a composite}/components/{a 
component}/services
                                                                         
/references
/query/services[binding,name,qname,...]



Each of the collections should allow searching by key attributes like "name", 
"binding type", ...

Repositories (and regular users) interested in SCA composites, components, 
services, ... could check regularly RSS feeds of appropriate collections.


That sounds very interesting. We could make the collection of composites in a domain as an Atom collection or RSS feed. It should be relatively easy to implement using the feed binding that we have or some REST binding derived from it or the HTTP binding that we have.

Once you've made the SCA metadata available on the Web, then it becomes really easy to reference it, feed it into a search engine, feed readers etc.


---

Recently, I've been thinking about turning the idea "Service Discovery for SCA" 
up-side-down - instead of discovering what is inside SCA, SCA runtime could discover what 
is outside SCA.

Imagine that Tuscany can read service definitions from a Repository or Registry 
(e.g. standard UDDI Registry). Then you can use any services (Web Services) 
registered in a Repository or Registry from your SCA application (component) 
without knowing anything about their deployment or implementation - that's 
*real SOA* :-).

When creating a new service in Tuscany, you could say: I want to use this service 
-"uddi:banking:accounts:AccountService"(service is determined by its UDDI key - UUID) OR 
"http://banking.com/accounts#wsdl.service(AccountService)".

<reference name="accountService">
                <tuscany:binding.uddi 
uddiKey="uddi:banking:accounts:AccountService"/>
</reference>

OR

<reference name="accountService">
                <binding.ws wsdlElement=" 
http://banking.com/accounts#wsdl.service(AccountService)"/>
</reference>

So, this way:
* I only need to know interface of a service (its QName from its WSDL) in order 
to use the service (I don't care where the service is deployed and where the 
WSDL is located - this information in maintained by a Repository or Registry)
* Tuscany can use whatever mechanism to resolve my reference using e.g. a UDDI 
Registry.

In the ideal world:

<!-- Tuscany could look through all "service by QName"-capable repositories for a 
service that I want to use -->
<reference name="accountService">
                <binding.ws wsdlElement=" 
http://banking.com/accounts#wsdl.service(AccountService)"/>
</reference>


Regards,

Mirek


Or - picking on your search idea - you could just do a search for the service descriptions published as REST resources in the domain that provide the interface you want :)

--
Jean-Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to