Microsoft's SOA in the Real World notes 09-Chapter 2
Chapter 2: messages and services
"SOA is not what you buy, but what you do ."
-- Jason Bloomberg
Analyst
Reader's gainsReaders in this chapter will establish the conceptual basis described in Chapter 1 and focus on the architecture functions of messages and services. The focus of message and service architecture functions is the service-oriented concept and how to use different types of services to implement SOA. This chapter also involves issues about user roles, especially how users interact with services in SOA. Topics in this chapter include:
- SOA Maturity Model
- Service Lifecycle
- SOA Sample Scenario
- Roles of users in SOA
The concepts involved in this chapter are not necessarily new. Many vendors, consultants, and industry analysts have published publications on SOA maturity models and service lifecycles. Like SOA itself, there is no Maturity Model and service life cycle that everyone agrees. Readers should study these achievements to find out the content that best suits their organizational needs.
Thank youThis chapter includes the achievements of the following people: Mark baciak (service life cycle), atanu Bannerjee (Oba), shy Cohen (Service classification), William oellermann (Enterprise SOA Maturity Model ), and Brenton Webster (SOA case study ).
Understanding services
SOA
Maturity Model
(
Another
??)Vendors, consultants, analysts, and authors propose a large number of SOA maturity models. Most of these models are built on sei CMM. When I recently searched for the term "SOA Maturity Model", I found nearly 10,000 links (including articles on how to find maturity models ). Since I am so interested in the maturity model and so many available models, why should I introduce another one? Unlike other maturity models, the models discussed here do not simply apply Service-Oriented to CMM. The service-oriented enterprise Maturity Model (esomm) draws on the capability-driven Maturity Model concept of CMM and applies these principles to the service-oriented model. It is basically a road map established from scratch. Different from cmme, the focus of the esomm maturity model is not on processes, but on whether the organization is ready and adopted, but on IT capabilities. Although similar to the CMM concept, esomm is a completely different application method of the maturity model. The layers, viewpoints, and capabilities defined in esomm have been used to support the service roadmap-not specific services with specific usage methods, specific implementation methods, or specific applications, it refers to any service, more specifically a group of services. (Not any specific service with any specific use, implementation, or application, but any service, or more specifically, any
SetOf services.) developing enterprise-level SOA policies is not trivial and cannot be considered as a short-term or one-time transaction. SOA tries to build a higher level of agility for the entire organization to better respond to customer and business needs. In many aspects of SOA, the recent goal is much more important than the long-term goal, so it is also crucial that the organization's efforts be aligned accordingly. In order to achieve this successfully, a roadmap with a priority needs a higher priority. Esomm provides an energy-based, technology-independent model that helps identify the current maturity level, short-term and long-term objectives of the Organization, and opportunities for improvement. Figure 2 is the summary of esomm. Esomm defines four levels of horizontal maturity, three vertical aspects, and 27 required functions to support SOA. Most organizations usually do not fully implement all the functions in a layer when moving up the layer in the model, but it is dangerous to jump too far forward. This becomes obvious when it comes to recognizing that some immature decisions related to key building block capabilities seriously affect the maturity at a higher level. Features are divided into three categories: implementation, consumption, and management. The focus of implementing functions is to develop and deploy Web services from the provider's perspective. The consumption function is to provide services to consumers so that they can be easily implemented, so they can be applied more widely and successfully. Management functions include those that facilitate the operation and governance of web services within the Organization. Because organizations can choose the maturity of the entire SOA, or the value of SOA, depending on the appropriate levels of attention in all three aspects. Esomm is a tool that can be used:
- Simplify the complexity of complex distributed solutions.
- Explore and identify the adoption of services by organizations.
- Understand the natural evolution of service applications (for example, skipping specific functions at a lower level ).
- Provide a cohesive and comprehensive service-oriented plan based on the customer's objectives.
- Align an organization's activities and priorities with a distinct level of value providing specific benefits through specific capabilities.
In SOA evaluation, each type of capability is evaluated separately, including the level of advantage, sufficient level, or shortage level. Advantage level. In a SOA assessment, each capability is assessed independently as a level of strength, adequacy, or weakness. A level
StrengthDemonstrates that the Organization is well positioned to safely grow their use of web services without fearing pitfalls in this area down the road. A level
AdequacySignals that an organization has sufficient capabilities to meet today's needs, but is vulnerable to a growth in Web services that cocould cause problems in that area.
WeaknessRepresents a deficiency that is a problem for today's use of web services and cocould be a serious detriment in the future. any capabilities that are obviously not part of the Organization's objectives and appear to have minimal impact in the near term for the Organization are classified
Not applicable. These areas may quickly become weaknesses if business or technical objectives were to change or accelerate. as in the CMM, individual capability levels drive an overall layer grade ranging from 1 to 5. A grade is assessed based on the average of the Capability maturities within the layer. A rating of 5 represents a mastery of that level with little or no room for improvement. A 4 represents a sol Id foundation within an area that can be successfully built. A 3 is assigned when good efforts are established in that layer, but extending efforts to the next layer carries some risks. 2 means that only initial efforts have been made in the area and much more work is needed to extend to the next layer. A grade of 1 represents no effort to address the capabilities at that layer. now that we have simply reviewed eso MM components should have been considered how to apply it to the Organization. It is clear that model applications should not be considered a one-time or short-term process. Instead, the model should be used in the work plan and can be modified at any time as the service usage and experience grow. Unfortunately, using the term model Maturity means that people immediately want to know the current state or level of their organization. At this time, there is no proper way to answer such a question: "At what level is my organization ?" Instead of giving the overall rating at a certain level, we use the we take the approach of giving each layer its own level of maturity, ranging from one to five, based on half-point increments. The purpose of esomm is to become a roadmap, not as a sign of SOA readiness or for SOA evaluation. Esomm is intended to be leveraged as a road map, more so than as an SOA-readiness or assessment tool. while it is important to know where you are, getting an exact bearing is less important than identifying the capabilities you need to address to continue advancing the value of service enablement in your organization. as long as you are willing to ask yourself some hard questions in an objective Manner internal SS all the relevant groups, you shocould be able to get a good understanding for your current challenges. if you apply the strategy and objectives of your organization, you should be able to identify which capabilities you will need to address in the near, short, and long term. esomm is one of the many maturity models used by enterprises to evaluate SOA adoption and implementation capabilities.... Unlike other maturity models, esomm can also be used as a roadmap to help enterprises successfully implement SOA. The purpose of esomm and other maturity models is to provide tools and information for the organization to successfully implement SOA and enhance its capabilities. Esomm is one of your possible maturity models that can be used to assess the capabilities of the enterprise in adopting and implementing SOA. it is necessary difficult to have a concise, constructive conversation about a service-enabled enterprise without some common agreement on capabilities and maturity-esomm is one of your maturity models that attempt to address this issue. unlike other maturit Y models, however, esomm can also be leveraged as a prioritized roadmap to help define ISES identify the capabilities necessary for a successful implementation. the goal of esomm and other maturity models is to empower your organization with the tools and information needed for a successful SOA implementation. to some extent, because new features such as registration and warehousing need to be developed, SOA makes the infrastructure more complex. In a way, SOA does render the infrastructure more complex because new capabilities will need to be developed that did not exist before, such as registry and repository. in some sense, it can be compared to the construction of a highway network-broad, safe roads are more expensive to build, and the users need to upgrade their means of transportation to make the most of that infrastructure, but the C Ost per trip (in time and safety) is driven down. until the network reaches a critical mass, drivers still need to be prepared to go-off road ‖ to reach their destination. using enterprise applications were not developed with SOA in mind, and are either incapable of leveraging an SOA infrastructure, or will need to be upgraded to take advantage of it. however, with more/new applications being creat Ed consistently, there is a great opportunity to drive down new Interoperability costs as the various technology vendors enable their products for SOA. the biggest challenge for SOA is convincing the application owners to invest more today to achieve those promised long term savings. although a maturity model like esomm can help identify the required capabilities of SOA, it usually cannot answer questions such as the type of service required in the Organization. Simple Service classification helps you better understand the typical scope of services in SOA.
