[pgfsoa-infra] Key messages

["Rollins, John" <jrolli01@xxxxxxxxxx>]

All,

I thought I'd take a shot at a few key SOA Infrastructure messages. No pride of ownership so feel free to comment.

1) The same principles that applied in managing "pre-SOA" infrastructures also apply here. The platform technologies such as the networks, protocols, OS's, storage, computers, etc. are essentially the same. The SOA Infrastructure, the subsequent services and applications are still beholden to that platform and must be managed in a similar way. Therefore, the same approaches for network/enterprise management are relevant, i.e. I have to make systems available, secure, monitorable, accountable, etc.

So don't throw away your enterprise management techniques.

2) In fact, SOA makes enterprise management a little harder. At its essence it encourages ad-hoc connections across the infrastructure. Consumers may use services in ways never conceived, and of course with unreasonable expectations. This can stress parts of the infrastructure that were architected with a "known-connection" mindset. Therefore, you must manage the infrastructure to ensure service SLA compliance, balanced infrastructure load, and priority resolution to accomplish mission goals. New tools that understand the SOA platform should be part of the SOA portfolio.

Greater freedom in employing services to solve problems requires greater management of the infrastructure.

3) Policies need to be declarative, centralized, and executable. Declarative: Human readable and represented as data, not code, so that they can be understood and changed. Centralized: From an operator perspective, he/she must be able to access the relevant policies. These policies may be federated across different stores, but the operator should have one access point. Executable: Policy Enforcement Engines, wherever they may live in the enterprise, must be able to execute the policies within the context that they are executed.

A self-organizing set of services requires accessible, flexible, changeable management policies.

4) The communications infrastructure used to invoke services, send messages, etc. must support flexible message exchange patterns. a) Lengthy request-response transactions within a distributed environment can cause chaos. The infrastructure should provide a range of invocation patterns that enable clients to experience synchronous operations, while the infrastructure implements asynchronous behavior. b) The infrastructure should allow service locations to be hidden. The client of a service should not be bound to its location; the infrastructure should take care of the routing and QoS. c) Point-to-point messaging often used by publish and subscribe components - especially with centralized broker scenarios - can cause immense performance problems. Alternatives that allow either federation of the publication or multicast of the information should be available.

The messaging plumbing is the key component to enabling services - you can't use what you can't get to.

5) Service profiles should not only state what consumers expect of the service, but also what the service expects of the infrastructure. A service can't meet its SLA's if it expects performance, QoS, etc. that can't be delivered by the infrastructure. These service profile statements could be inputs to management policies.

There's no sense offering services that can't meet their SLA's.

Thanks,
John

_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/pgfsoa-infra/
Subscribe/Unsubscribe/Config: 
http://colab.cim3.net/mailman/listinfo/pgfsoa-infra/
Shared Files: http://colab.cim3.net/file/work/pgfsoa/pgfsoa-infra/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?PracticalGuideToFederalSOA
Community Portal: http://colab.cim3.net/
To Post: mailto:pgfsoa-infra@xxxxxxxxxxxxxx    (01)