Re: Service Discovery for SCA
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.
---
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Service Discovery for SCA
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]
Re: Service Discovery for SCA
I agree that this would be useful. The place to enable it would be the SCA Domain. The Domain doesn't currently have APIs to list or search for services. We could add APIs that do this, or we could add an SPI that allows a registry to plug in to the Domain and be informed whenever services are added or removed. The latter seems better to me, as it would be easier to keep the registry in sync with the Domain. I'd be interested in other views on this. Simon Miroslav Novak wrote: Hi, SCA allows to describe components (services) in a standard way. It would be nice to expose this information so that it can be automatically discovered and stored in a repository. Later, when developers are about to create a new component, they can search existing SCA components that they could reuse. Do you plan to expose definition of SCA components via some API? Regards, Mirek __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Service Discovery for SCA
On Dec 6, 2007 1:32 PM, Simon Nash [EMAIL PROTECTED] wrote: I agree that this would be useful. The place to enable it would be the SCA Domain. The Domain doesn't currently have APIs to list or search for services. We could add APIs that do this, or we could add an SPI that allows a registry to plug in to the Domain and be informed whenever services are added or removed. The latter seems better to me, as it would be easier to keep the registry in sync with the Domain. I'd be interested in other views on this. Simon Miroslav Novak wrote: Hi, SCA allows to describe components (services) in a standard way. It would be nice to expose this information so that it can be automatically discovered and stored in a repository. Later, when developers are about to create a new component, they can search existing SCA components that they could reuse. Do you plan to expose definition of SCA components via some API? Regards, Mirek __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi I agree this would be a useful thing to do. Maybe we need both approaches. Consider these. 1/ Some 3rd part resgistry wants to keep in synch with the service endpoints that are running within the SCA domain. I think that in this case having an interface where a listener can register for service registration change events would be a sensible approach. 2/ A users wants to retrieve service information from the domain in order to browse service registrations through some management GUI. In this case we can to be able to retrieve all services or services by name. So in this case the interfaces which allows information on named services to be retireved seems most appropriate. As it happens the Nodes currently register with the Domain and then use and interface to find named service information (like 2) . However I really need to flip this round and broadcast information to nodes as services come and go (like 1). Doing this is actually fairly straightforward however, as is always the case with these things, the hard part is what the interface should look like. I need to expand this as currently the node implementations don't any account of policy at the domain level. They should do. I would like to have the ability to get at the full definition of a service and the bindings it has. I may even be better to allo a complete component definition to be moved about. Regards Simon
Service Discovery for SCA
Hi, SCA allows to describe components (services) in a standard way. It would be nice to expose this information so that it can be automatically discovered and stored in a repository. Later, when developers are about to create a new component, they can search existing SCA components that they could reuse. Do you plan to expose definition of SCA components via some API? Regards, Mirek __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
