tigretigre.com

It's about time I started getting down to brass tacks on how I will implement a proof-of-concept of my SOA-based content aggregation scheme. I guess for that, I'm going to have to build some services. I'm taking an object-oriented approach, and hopefully one that can be applied in multiple languages/platforms and can be used to implement services using a wide range of protocols. I tried Googling around for existing class hierarchies that would meet my needs, but if there were any they were drowned in a sea of less general solutions. Semantic Web, where are you when I need you? Anyway, I may well have missed something good, but in the absence of anything better I will forge on ahead with my own humble design.

I only have time right now to put up some broad strokes. More details will, I hope, be forthcoming. But without further adieu, here are those aforementioned broad strokes:

Here are the main classes, and some subclasses worth mentioning:

1. Protocol - contains factory methods for creating either end of the communication channel, what I am calling Port (the service-side, which listens and responds) and Plug (the consumer-side, which requests and receives the response). Any concrete Protocol subclass will produce concrete Plug and Port objects for the protocol in question. Although the immediate subclasses that spring to mind are SOAPProtocol and RESTProtocol, there are of course others at that level, and still more possible subclasses below these, such as AsynchronousSOAPProtocol, to implement the asynchronous query pattern.
2. Service - Services contain a certain number of Plugs and Ports as specified in the subclasses, which can potentially change on the fly. Multiple Ports can support multiple protocols for accessing the same service. When a Port receives a request, it calls the "get-response" method of the Service, passing the request data in a common format (probably yet another class, but I haven't decided that for sure yet). If answering that request requires accessing other services, the Service passes its own requests along to one or more of its Plugs. The main subclasses of this will be:
   1. MappingService - An adapter that takes the end service and presents it in a form that the aggregator can use. For the sake of my proof-of-concept, and possibly in a real-world scenario, at least some of the mapping services will patch straight into the social networks rather than using poor or nonexistent social-network Web services.
   2. AggregatorService - Pulls together content from the mapped services, and distributes content out through the mapped services.
   3. AuthorizationService - A service that mediates between the user (or a service) and any intermediary services that require it to make sure that the user (or service) has the right to make the request. This is where micro-payments would fit into the picture.
3. Plug and Port - These are responsible for translating between the actual network transmission protocol and the Service's internal representation. So they are at the heart of the loose coupling at the heart of SOA. They must each be implemented with no assumption that they are connecting to an instance of the other, since of course the protocol should be able to handle interaction with services regardless of implementation. A Port listens for any requests and passes them into the service, while each Plug is configured to send requests to a specific service (which would be a Port, if the other end happens to be implemented using this same class scheme). My end client will have a Plug wired to the AggregatorService's Port.

Well, that's it for now. It's even more than I thought I'd get out at the moment, but of course far less than will be needed to get something running.