SOA Infrastructure Management (3FOS)
- 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. (3FOT)
Comment: Do you mean the enterprise mgt techniques that made legacy systems so available, secure, monitorable, accountable? ;) (3FQO)
- 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. (3FOU)
Comment: Why does greater freedom require greater management? Wasn't the opposite true of the internet? (3FQQ)
Network and Communications Infrastructure (3FOV)
- An important enabler for SOA is Web services and one of the critical components of SOA Governance is SLA. (3FOW)
Comment: SLA=Service Level Agreement? (3FQS)
- Renewed IT investments are driven by increasing demands for more efficient communications and information sharing across disparate agency networks. Increasing volumes of data required for decision support results in progressively more complex data management environments. Web services, which use distributed software programs and applets that form building blocks for application development, operate across geographically dispersed computing platforms. The need to reference multiple applications physically residing in geographically distributed locations creates additional traffic and service management challenges. Controlling large quantities of intersystem traffic requires robust, flexible networks that provide high levels of network performance (i.e., low latency and high throughput) to enable a high-quality user experience (3FOX)
Comment: Isn't this a problem the govt wants to have; i.e. many services, heavily used? Isn't the obstacle the absence of any (policy-compliant; secure+interoperable) connectivity at all? Shouldn't the policy guidance be 1) establish secure+interoperable foundation, 2) build services on that foundation, 3) decide how to manage problems as they surface, 4) evolve and improve. (3FQU)
- With respect to network SLA, agencies increasingly focus on data availability and protection as they implement solutions for continuity of operations (COOP) and disaster recovery (DR). Data transport between primary and backup locations, often separated by hundreds or thousands of miles, is integral to effective COOP and DR strategies. As data backup needs increase, agencies must weigh the risk versus importance of the data and balance this by providing an affordable, secure and highly adaptable network solution. Increased user demands on agency networks, coupled with the growth in latency-intolerant and bandwidth-hungry applications, often exceed the capabilities of existing network infrastructure. (3FOY)
- A disjointed network architecture with multiple transport technologies managed by a mix of in-house and third parties contribute to the limited interoperability of networks and applications. Taken together, these factors drive network planners to seek flexible, adaptable and manageable WAN solutions. These WAN solutions include private optical networks and managed wavelength services tailored to the networking requirements and cost constraints of government agency networks. (3FOZ)
Comment: How would you avoid "disjointed network architectures", when each project stovepipe builds its own infrastructures because of the difficulties of funding infrastructural development? (3FQW)
- 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. d) The messaging plumbing is the key component to enabling services - you can't use what you can't get to. (3FP0)
Portal Infrastructure (3FP1)
- To implement a service-oriented architecture (SOA), companies must consider what steps and technologies are involved. Portals represent a logical first step in the process. (3FP2)
Comment: Why isn't the first step to deploy a foundation infrastructure capable of secure+interoperable transport? (3FQY)
- A portal can clarify the sometimes confusing SOA concept for an organization’s IT staff and end users. An enterprise portal project pulls together the disparate groups involved in cross-enterprise technology projects. No other technology is more tangible than a portal, and IT professionals and users can relate to it. Portal products have leveraged service-oriented concepts since 1998, so they provide a natural approach to SOA. It leverages Web services extensively. It leverages portlets, which consume services or communicate to provide orchestrated flows and on-the-glass composite applications. (3FP3)
Comment: Why build a portal before there are any services, or even any transport infrastructure capable of reaching them? (3FR0)
Policies and Services (3FP4)
- 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. (3FP5)
- A self-organizing set of services requires accessible, flexible, changeable management policies. (3FP6)
Comment: Why? Please justify this claim. Are these requirements necessary? Sufficient? (3FR2)
- 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. (3FP7)
Comment: Comcast provides no SLA (and often fails to meet even that), yet I find internet services useful. The same is true of non-computer capabilities; i.e. US Postal service. Please justify and explain this claim. (3FR4)
Meta Data Management (3FP8)
- Although promising as a new method for building applications, SOA will fail if long-standing data quality, data redundancy and semantic inconsistency issues are not addressed. Unless Organizations take a disciplined approach toward enterprise wide information management, the SOA method of development may become fraught with highly redundant and inconsistent data stores and data integration applications, which is no different than today's reality in most large enterprises or Gov. Organizations. Complex or conflicting sources, inconsistent semantics and poor quality data (previously hidden and protected in tightly coupled systems) are suddenly exposed during service composition, creating confusion as multiple developers try to achieve efficiency and reuse. (3FP9)