SOA is not a product, but an architecture and the prescribed approach is now finding its way (quite violently sometimes) into the network. Let us start with the framework. We need to create a point of indirection between a network device (the service provider) and the end station (service consumer). That point of indirection is the repository where network devices register their service and its scope. The same repository should support a querying mechanism that returns a service description to the initiator of the query. We need a stack on the initiator which understands the description (i.e. no human involved) and can initiate a peering relationship with the service provider whose service description was returned as response to the query. We also need the repository to differentiate between a cataloged service (inventory) and a service instance (presence). We also need the repository to be available at a well known address because the network device is factory configured to find its repository. Finally, we need a service that creates this repository service should one not exist (when the first network box is deployed for example).
The next question is what is the protocol of communication that will support a conversation between the end station, repository and peers that are present. This is where folks gets in own way. For cataloging, we don't need presence information and for presence we do not need to be cataloged. One requires a session oriented protocol while the other requires a simple request/response. Both these protocols exist in inustry.
Where further work is required is description of the service and that is where the crux of the whole architecture lies. Here we need to take care that we don't fall into the trap of describing our CLI as XML.
