Context Navigation

Service Oriented Architecture

Service Oriented Architecture

Is corporate rock and roll or real thing ?

A useful collection of standards ?

See a way old Introduction to SOA presentation on the way old BBcom site. It may still be useful.

Core SOA

http://en.wikipedia.org/wiki/Service-oriented_architecture

Service-oriented architecture (SOA) is a design pattern based on distinct pieces of software providing application functionality as services to other applications via a protocol.

[ Sounds a bit rock-and-rollie ]

Oasis definition: A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

http://en.wikipedia.org/wiki/Service-oriented_modeling

http://en.wikipedia.org/wiki/Service-oriented_architecture_implementation_framework

http://en.wikipedia.org/wiki/SOA_governance

http://en.wikipedia.org/wiki/Governance_Interoperability_Framework

Sort Of Agents

http://en.wikipedia.org/wiki/Semantic_service-oriented_architecture

http://en.wikipedia.org/wiki/Software_agent

Sort of Actors

https://en.wikipedia.org/wiki/Actor_model

... In response to a message that it receives, an actor can: make local decisions, create more actors, send more messages, and determine how to respond to the next message received. Actors may modify their own private state, but can only affect each other through messages (avoiding the need for any locks).

Not entirely avoid locks, there's always XMLRPC lurking in the dark somewhere ... maybe no locks at the logical/application level.

... Hewitt argued against adding the requirement that messages must arrive in the order in which they are sent to the Actor. If output message ordering is desired, then it can be modelled by a queue Actor that provides this functionality.

Interesting practical point, a message queue is not a processing queue - it can be modelled that way but there is a fundamental difference between the two. Paying attention is small info-nuggets like this can save large amount of development time.

My workaround to the message ordering problem is to create a temporary one-shot queue ( address 'myqueuenameEdxx33F' ) with a <reply-to> directive in the header. Read/write permissions can completely lock down the queue. There is overhead, but so long as message level is less that 1000 per second, the Python multiprocessing QueueManager chugs away nicely.

https://en.wikipedia.org/wiki/Actor_model_theory

https://en.wikipedia.org/wiki/Actor_model_implementation