Reasons and opportunities for choosing SOA

Introduction

Service-Oriented Architecture (SOA) has become a de facto standard for developing component-based applications that can be accessed over a network (Internet or other network) using standard interfaces. At least IBM senior management and many other vendors, analysts, consultants, and software developers say that. They will also tell you that the entire industry is gradually adopting SOA. If you have not started SOA development, you will soon be unable to keep up with the pace of the times.

When to use SOA and when to not use SOA

One of IBM's goals is to develop and adopt open standards within its products. By doing so, you can realize the value proposition of SOA in your company's IT infrastructure. SOA can optimize the consistency between business requirements and it, separate business process activities from service implementation, and reduce operational costs. These functions can be truly implemented only when there is no fixed supplier. In this case, the technology for SOA implementation can be seamlessly integrated (consider: "Open Standards") to build a comprehensive end-to-end solution.

When strategic business goals and activities are taken into account, the theoretical SOA concept is very attractive and more easily supported. However, it is not easy to decide to implement SOA. This is similar to changing the way of life, because the development and operation teams follow completely different it control modes. I advocate business-driven development. This process involves refining business requirements into IT requirements, and then refining it requirements into it functions to determine the technologies required to meet these needs. Based on my experience in developing Web service-based solutions and more sophisticated SOA-based solutions over the past four years, the following factors often make me recommend a service-oriented architecture:

• The cost of integration continues to grow, rather than being mitigated by new business opportunities that provide real ROI.
• Mergers and acquisitions are at the core of your company's business model for expanding market share and gaining new development opportunities.
• The solution requires integration of business functions from heterogeneous systems and programming models.
• Business survival depends on the ability to quickly adjust or respond to competition threats based on market changes.
• The impact of the global economy requires your company to do business with half the effort, and it is necessary to rely on business partners to provide non-core business functions.
• To improve profitability, collaboration with business partners is critical to your company.
• The value of your company's business assets is decreasing because you cannot evaluate it for use outside of its original use.
• The efficiency of your company's employees is faulty because most of their time is not spent on providing the core functions and services of the company's business model.
• Your company's business is full of opportunistic business work.
• Your company starts developing new applications from scratch. (I think SOA should serve as the default architecture style for identifying future new applications, except when there are other restrictions on business conditions .)

Ideally, there is no budget limit, Plan term, skill gap, or priority difference between you and your business partners. In this case, we can say that everyone will adopt SOA, or at least SOA will be considered. However, our choices are often influenced and limited by past decisions (such as technology investment, programming model adoption, service contract agreements, etc ). Therefore, we cannot always use the best options that seem to meet a specific business or technical requirement. The following considerations make me not recommend using a service-oriented architecture or describe the marginal benefits of implementing SOA:

• Your company only uses a small amount of IT budget for integration activities.
• Most of your company's processes are manual or document-centric, and there is almost no chance of automation.
• Most of your company's application development uses the same programming model.
• Your company's operations are managed by one or two Customer Relationship Management (CRM) and enterprise resource planning (ERP) applications, with almost no integration requirements.
• There is a major difference between your company's existing skill Library and the skill library required to implement the infrastructure that supports SOA.
• No business needs or opportunities were found to benefit from the functions provided by SOA.
• The availability of new business services will have a negative impact on the existing revenue streams.
• The business partners on which your company depends take different priorities for the automation of inter-company processes.
• Your company's main business involves massive transactions with high synchronization and real-time requirements.

The previous list is just an example to illustrate whether SOA is the best choice for your company. Of course, each contract or project has a unique requirement, so the decision on when to adopt SOA depends on your company's business conditions. SOA's value proposition is very attractive, but when to make your company adopt SOA, you must consider the actual situation of the business environment. The adoption of SOA does not have to take a big step, but is usually conducted in a step-by-step manner. First, find a project that can use the concepts and principles of SOA, and then use the main performance indicators to determine its value. This is a good way to benefit everyone.

Integrate services with it

SOA is not only a development example. This architecture is used to build an intermediate location between the business and IT, including a group of IT services agreed by both parties to be consistent with the business, these services are combined, to achieve the business processes and objectives of the Organization. This example provides unprecedented flexibility: it allows the structural composition of business processes to be separated from services that provide functionality for each activity in the stream. It also allows separating the business implementation from its description. After this separation, the company can incrementally change its backend legacy systems and add new features to support new requirements without being limited by vendor selection. Therefore, you can replace software packages and custom applications with minimal impact on business processes and IT systems.

The next step to separating access functions from its implementation is SOA. In addition to this function, we can also externalize non-functional aspects. For example, we can determine who should be able to access specific features based on the established business policies. We can also define how to manage technical resources that we want to access in a flexible and reconfigurable manner.

This architecture is the next step in software engineering development. It enables us to switch from structured objects to distributed objects and components, and then combine business and it with a set of public services (these services are combined together, can achieve the process and goals of the Organization ). SOA also allows some of the company's business processes to be made public to partners in the ecosystem.

SOA can be used when it flexibility is needed to support business flexibility. Therefore, SOA is a perfect choice for industrial applications that need to communicate with and access the combined business process.

When using SOA technology, real-time or passive systems are generally not the best choice for implementation, because the current technology does not support the use of SOA in real-time systems with a large number of concurrent use cases. However, the modeling of these systems can also benefit from the separation and independence concepts provided by SOA.

SOA is ideal for eliminating redundancy and combining it functions that are not tightly coupled with specific services. It allows service users to select a backup service provider (not only based on functions-I need similar functions, but not additional dependencies in services of this version, you can also choose based on the design and runtime policies and Web Service management functions ).

Enterprise Architecture SOA-based companies have a stable foundation and can abstract business functions from existing system concepts. They also have the foundation to allow business-driven it conversions in an incremental manner as new software packages, systems, and assets are available and new needs emerge.

An important but slightly inadequate mechanism

In the scope of enterprises, a large number of innovations have emerged in the following two aspects: Enterprise edge and enterprise. On the edge, we can see that the framework on the middleware has invested a lot of effort (a domain-independent framework, such as Ajax, and a domain-specific framework, integrates with specific industries), and has invested a lot of energy in device-related work [typical mobile devices and radio frequency identification (radio frequency identification, RFID) marked device]. Between enterprises, we can see the formation of systems (legacy systems and new systems.

In such a web-centric system, services have been proven to be an important mechanism in these two aspects. On the edge, services provide behaviors that go beyond basic technologies. Services between enterprises provide powerful communication modes with rich semantics between systems.

In this case, the service is an important but inadequate mechanism in the system structure. This is too simple, but in general, the service is not very suitable for high-frequency or very small-granularity connections. Moreover, services are certainly not the only decomposition mechanism suitable for the architectures of various systems.

SOA and Web Services and advantages

 

SOA is an abbreviation of excessive usage. It is used (abused) by senior management personnel to developers to convey multiple (sometimes inconsistent) semantics. In my opinion, a service-oriented architecture is a framework used to integrate business processes and supporting technical infrastructure as standardized and well-managed components-services, services can be combined, reused, and adjusted to meet changing business priorities.

New users of SOA think that SOA and Web services are equivalent. There may be effective SOA-based solutions that use existing IT assets (from mainframe transactions to object-based systems) without using any web services. Moreover, I have seen several departments-level Web Service implementations that are not effective SOA applications. These web service islands generally do not fully follow all core SOA principles and features-they may not be loosely coupled, unabstracted, reusable, componentized, or not independent of platforms and protocols, most importantly, they may not provide real business value.

As web services provide a level field for innovation and interoperability between infrastructure and application vendors, many standards, summaries, and terms have expanded this confusion. Web services are only a collection of standards and technologies (there are many other technical support options) to implement SOA-based solutions.

In a rapidly developing global economic environment, enterprises must maintain sufficient flexibility to maintain their competitive advantages. This advantage can be provided and maintained by combining IT infrastructure with core enterprise processes using SOA principles. Therefore, the question of understanding and adopting SOA is not how or why, but when? SOA-based enterprise solutions have been proven to simplify business operations, improve efficiency, reduce costs, and eliminate redundancy.

However, to achieve these benefits, SOA must be correctly applied. It must have a vision and Transformation Roadmap within the corresponding enterprise scope, financial support and commitment from business executives, and be deployed by experienced architects in incremental iteration mode. These incremental steps should first focus on key business issues, and the final solution should provide business value. This helps maintain and promote the use of SOA for end-to-end Enterprise conversion. In the process of adopting SOA, SOA will face a variety of major challenges, including political and cultural diversity.

From a purely technical perspective, the SOA platform (including tools and runtime) is also undergoing a huge transformation. The development tool environment contains a large number of modeling tools, deep-rooted industry scenarios, reuse models, solutions, rich visual representations and controls, and simulation technologies. The runtime is also evolving to provide enhanced service quality, declarative and policy-based management and attractive management and monitoring of dashboard (for IT and business events ), use automatic tools with self-repair function for detection. We are at the forefront of every aspect of the solution lifecycle, while SOA is the key catalyst. However, in the long run, if we are not careful, this abstraction and ease of use may leave the fundamental foundations of IT architects or developers and computer science and technology out of touch.

Model-driven development and Virtual Enterprises

You may have chosen to use SOA. Most medium and large enterprises apply SOA elements in their application design. Well-structured CICs and IMS programs generally comply with SOA requirements. Many companies have built a distributed system consisting of message-driven applications. Session Enterprise JavaBean is "SOA-like ". Many isV systems use a service-like structure, such as SAP idocs. SOA systematize the Guidelines for well-structured distributed systems and is a subset of the concepts of Structured Programming and Model Objects (OO) and a natural development of message-driven processing.

Web services are a set of standards used to build SOA solutions. Infrastructure Providers (IBM, Bea, Microsoft) and application providers (SAP, Oracle) use web services as quickly as they use any software technology. In a short period of time, our industry's runtime interoperability [Simple Object Access Protocol (SOAP), HTTP, WS-Security, WS-reliablemessaging] and interoperability between development tools [Web Service Description Language (WSDL), WS-Policy, Business Process Execution Language for Web Services (BPEL4WS)] has reached an unprecedented level. This interoperability reduces the cost of migrating to SOA, making it easier to obtain the benefits it brings.

What are the benefits? All or any single benefit will not be discussed in detail here. I will briefly introduce two advantages:

SOA supports model-driven development and solution monitoring from the business perspective. We have made great progress by using Websphere Business Modeler to generate a tool that allows analysts and business professionals to deduce and design their business processes. SOA operations are the natural presentation of tasks or steps in a process, while the implementation of composite services (BPEL4WS, business state machine) is the natural representation of the process. Based on simple business rules (enabled using WebSphere process server), WS-policy and service implementation are both natural representations of business policies.

Web Services Support "Virtual Enterprises ". Previous technologies such as MQ and Common Object Request Broker Architecture (CORBA) are mainly optimized for enterprise computing. Both the Web service protocol and WSDL can work in the Internet and internal network. In this way, we can use the same model used for internal enterprise application integration to implement simple and rapid development of the opportunity B2B on the Internet.

Control Problems

SOA is similar to other software modular processes that have existed in the IT industry for 30 years or longer. The different hardware and networks of SOA are mature enough to support this standard-based technology. In any aspect, SOA is not a popular technology in the past, but it contains a wide range of industry standards and support.

SOA provides an opportunity for enterprises to identify their core competencies and decide whether to provide these competencies as services to their industry and business partners. On the other hand, the fact is that an enterprise can identify the processes and applications that are part of its core infrastructure (not its core competencies) and then determine to purchase them. Note that some of these services (provided or purchased) are only for business processes. Enterprise Architects can take the lead in carrying out relevant work to find business processes and it processes with a public function set in the enterprise. The execution function can be packaged into components with little external dependencies and provided as a service. This simplifies the work of Business Process creators or application developers to focus on the unique feature that can satisfy the shareholder's business motivation.

It is not a technical issue to make SOA work normally. Making SOA work properly is a matter of business control and it control. Technical experts can construct an SOA Implementation Based on many existing success models. Then let the enterprise use these services instead of creating them on its own. This is another problem. Appropriate architecture controls will identify the projects whose services are available for new applications. The only way to make SOA investments worthwhile is to enable senior management personnel to commit to controlling the budget, or to take some way to ensure that the business line is not disturbed. It Architects also need to report business value gained from their SOA investments and investments to the executive shareholders.

In order for SOA to collaborate with business partners, the relationships established by the enterprise need to be involved. Currently, few (if any) customers provide or purchase services to partners outside of their established contractual relationships. Service level agreements and dispute resolution issues require a closed collaboration system. Organization for the Development of Structured Information Systems (OASIS) standards on trust and security have made great strides over the past two years, however, on the legal and business side of the equation, it is still more inclined to carry out such business with partners that enterprises know.

There is no myth here

There are three simple reasons for considering SOA:

1. This is one of the most popular fields at present; do not lag behind the pace of the times.

2. Tools, infrastructure, and standards are combined to provide comprehensive support throughout the SOA lifecycle. Understand our end-to-end programming model. Follow the detailed steps provided here to experience the success.

3. If you continue to get twice the result as we do, SOA can help you. Find something you can reuse. Do not start from scratch. Find and adjust existing services and use them. Then share some of these services. Helps create an ecosystem so that more meaningful solutions can be assembled more quickly in the future.

There is no difference between the adoption of SOA and the adoption of any other technology or architecture. This problem can be viewed through common sense. If your project is in a critical position and your team has to invest a lot of effort in learning tools and APIs, it may be a wrong choice. If you can try SOA in a small project, it is a good choice. Using this experience can help you define and extend it to the next larger project. Step by step. There is no myth here.

Just business

 

SOA supporters constantly publicize the main technical advantages of SOA: loose binding, ability to encapsulate reusable business functions through components, and finally (but not as deliberately emphasized as usual) it also provides better integration.

I am also one of the supporters of SOA, but I am constantly asking myself one question: are customers really interested in this technical inference?

Over the past two years, I have been fully cooperating with clients who want to obtain the value proposition produced by SOA. When communicating with customers, I often find that customers believe that many other architectures provide more technical value than I mentioned. Some customers may come to the wishful thinking conclusion that very experienced architects and development teams can gain great value by using the traditional enterprise application integration (EAI) architecture. Many customers argue that these methods have been verified and there is no high risk of directly adopting SOA for implementation.

This idea may make architects realize that in some cases, SOA is a wrong choice, or, at least, it is not the best choice. Is the technical feasibility of SOA the reason for choosing it as the architecture method to solve a series of business problems? I would say no: many business and IT-related issues (such as the lack of strong enterprise control models and policies) will slow down or impede the implementation of any well-conceived technical SOA activities.

At the last three-day SOA seminar, a CTO of the automotive industry told me: "My Opinion on SOA is just business '." He told me that the reason for his SOA adoption is:

• Increase the speed at which he and his team implement new products and processes or change existing projects
• Reduce implementation and ownership costs
• Supports flexible pricing models by outsourcing business elements or changing from fixed pricing to variable pricing (based on business volume)
• Simplify integration required for Merger and Acquisition
• Achieve better IT usage and ROI

The CTO and his team only care about how to use their existing skills (without having to discard their existing infrastructure) to achieve these goals on time within the budget. They have invested heavily in their existing EAI infrastructure.

The special CTO statement is different from that of many others. They only care about the key: How can I return to shareholders?

Of course, as an experienced architect (smiling), I know some architecture alternatives to solve this problem:

1. Expand its existing EAI infrastructure

2. Plans to adopt more event-driven architectures (completely isolated, publish/subscribe, etc)

3. SOA may be available

Since this is an SOA seminar and the customer pays for it, I was initially prepared to select the third option. In fact, I used a little EAI, a little event-driven, and a lot of SOA. SOA allows EAI and event-driven methods to be included when necessary.

For the rapidly developing automotive industry, enterprises must be flexible to maintain competitive advantages and provide products within the budget on time. This customer's difficulty lies in managing and merging their business processes. As my colleagues have pointed out in this discussion, integrating IT infrastructure with core business processes is critical to achieving the goal. SOA-related principles have been proven to simplify business operations and reduce redundant items that have little to do with actual Code and are concentrated on human-computer interaction and human activity. In a business environment with limited funds, almost no customer can invest unlimited funds to solve specific business problems, and fewer customers who have time and are willing to trim their control processes. It sounds good, but it does not actually do this.

The key lies in the use and expansion of existing infrastructure, processes and existing control models. By appropriately using existing SOA principles, you can manage the entire design and implementation process, for example:

1. Identify problems.

2. Identify the processes that make up the business and are difficult.

3. Model these processes to simplify them.

4. Identify existing services and write other services that represent these processes.

5. deploy these services in an environment that provides runtime functions and has high operational efficiency.

6. monitor these services and processes for higher efficiency.

What about the network? Although we do not know what the solution is, we should look at every problem objectively. Determine whether to adopt SOA Based on technical and business indicators. Use it if appropriate. If not, you don't need it. SOA concepts and principles can always be applied to your architecture in some way.

Kangzhuang Avenue

We should now be aware of the industry-wide ROI for SOA and the word of praise for adoption-loose coupling, better reuse, shorter time to market, easier integration, and better interoperability. However, we must understand that our current focus on SOA is only an important step in the process of implementing plug-and-play enterprises (or on-demand enterprises.

As we enter the next decade, we will begin to substantially reduce the workload required to combine products or components from different IT vendors into a viable and valuable end-to-end solution. The business components provided by the supplier are not dependent on the infrastructure and can be executed on various platforms. Therefore, software developers focus more on effectively integrating supplier components and ensuring effective interoperability.

The customer's IT Operations Department is mainly responsible for selecting the runtime platform that best suits the business needs; that is, the platform that provides necessary service quality and runtime support for proper deployment and management of business components.

On the contrary, the IT Business Operations Department will focus on how to implement the business policies of the Organization by defining business components (which will be deployed and managed by their corresponding operators) including business rules. This will be done through a business process management system such as Websphere Business process server.

The IT Business Operation Department will be staffed by business and enterprise architecture professionals. No matter how you define the business or enterprise Architect: To achieve this vision, the industry will need more people with it and Enterprise Architecture backgrounds.

Although this vision may be very attractive, there are still great risks. before entering the component Heaven, we must be careful to reduce these risks. When starting to implement the architecture of model services, the most important risk reduction method may be to require strong management of control processes and policies. Only through powerful enterprise service control policies can we avoid the problems of changing management, semantic mismatch between services, and integration of system functions that are difficult to debug. The IT department can reduce risks by developing control policies that are proposed and supported by the executive supervision team (including CIO, CTO, and business line executives.

Improve information

Of course, you already know about SoA. You also know the importance of web services and business processes, the model-driven architecture, and all these open-minded WS-* standards.

However, you may be an information engineer. You are responsible for the integrity and analysis of the Organization's information. You are concerned about the performance and stability of databases that indicate the business status. As you know, what really matters. Therefore, you may ask, "Why should I care about SoA ?"

As an information personnel, I am very concerned about SoA. I care about SoA because SOA has the ability to directly and indirectly affect information management systems-in fact, it can affect information itself. To succeed, we need to consider the information involved in the business service. We need to know that the retrieved information is accurate. The updated information has been verified. The meaning of exchanged information is the same for service providers and users. If you ignore these things, the value and reusability of the Service will be reduced.

Directly speaking, when using SOA, we need to form an Information Agreement between the provider and the user so that the parties can understand the meaning of the information and still support heterogeneous systems-in other words, we must assume that the world is disorganized and organized to increase the value of information and understand the relationship between different structures and meanings, and, if possible, reach an agreement on public objects.

Disclosing information as a service also allows us to configure an additional information server topology to accommodate the increased information load. It also requires us to establish virtual points for information access (so that users do not need to know the real location of the information and the way the information is organized ). It also introduces methods that allow us to effectively combine the information-through a set or combination. If more public mechanisms are not established or improved clearance mechanisms are introduced, we are likely to be forced to invest a huge amount of additional funds and resources to clear them later, resulting in a reduction in future flexibility.

There are many ways to implement information agreements. One of the more important is the primary data management (MDM) field. The MDM system provides cleared, consolidated, and domain-specific information for business applications or services. The most common MDM system is used as the information hub of customer and product information. Each hub is used as a central point where you can add, update, review, clear, search, and query information. A hub is placed at a location where changes can be propagated to the relevant database or events that can produce services. The MDM system can be transactional (updated in the main line of the Business Process) or referenced (providing consistent sources of information referenced by the Business Process ). But most importantly, we can regard the MDM system as itself providing a consistent set of services for use and reuse in various business processes.

Using MDM and other methods to explicitly implement agreements between information providers and users can help us achieve flexible business processes and service reusability committed by SOA, it also provides us with opportunities to improve the quality of managed information.

Applicable and unsuitable scenarios, as well as areas needing attention

SOA is an organizational method used in application architecture composed of service-oriented and distributed object computing. Let's divide this definition into several parts for analysis. The application architecture is a broad organization of each part of the application, which is usually implemented as a layer. The architecture specifies what is included and how they work together. Services encapsulate functions as services-a broad reusable task that can run without any previous context (except the current domain status of the system hosting the service. The context of the service is provided as a parameter passed by the caller, which is very similar to the parameter of function call. Distributed Objects run in independent processes in a specific way. In this way, objects in one process can call methods on objects in another process.

SOA adds services to distributed objects to call services between processes. It is a method used to design the application architecture so that each part of the application can run in different processes, it also allows different applications to share and reuse the running part. It is the evolution of Distributed Object Computing to achieve a better balance between multiple pairs of cubes: applications that need to access each other's functions; applications that need to encapsulate their own functions; applications that require public functions described in their application programming interfaces (APIS) and interactive applications that require distributed calls must be restricted. The Service supports access by publicly encapsulating good functions through APIS defined by various tasks, so that high reusability of functions can be achieved through low-frequency calls. SOA is perhaps the best of all methods.

The following provides some simple techniques to determine when to adopt SOA and when to avoid SOA and situations that require greater vigilance.

First, it is suitable for SOA:

• SOA is used when data distribution is very high. Place the code of the operation data near the data, and package it as a service for access anywhere.
• If you want high availability of features, use SOA. Deploy functions as services in multiple redundant providers, so that other peer services can be used when some of them are unavailable.
• SOA is used when each part of an application needs to be independently developed, maintained, and updated. Each team (such as two different B2B companies) can use their favorite technologies to implement their respective parts as planned, as long as they maintain interfaces between different parts.
• SOA is used when multiple applications need to reuse functions and data. Shared code only reuse functions. The service allows independent applications to reuse a group of shared enterprise data without distributing data to all applications.

SOA is not suitable for the following scenarios:

• Do not use SOA when you want to make development as simple as possible. It is implemented in one language and runs in a single thread, and applications without remote access problems are less complex, so it is more convenient to build and debug.
• Do not use SOA when you want to make the operating environment as simple as possible. It is much more difficult to troubleshoot loosely coupled and event-driven distributed applications. You must have a thorough understanding of the application implementation details, operating environment configuration details, and the current status.
• Do not use SOA when the network is unreliable or the network speed is slow. Service Components run on independent computers and communicate over the network. Therefore, their speed and reliability depend on these computers and their networks.
• (Note: The distributed redundancy service can help reduce the impact of hardware reliability and network latency .)
• Do not use SOA for prototype design. Prototype Development should be simple, while SOA is not simple.

When you need to be vigilant, frankly speaking, always be vigilant. The following are some situations that require caution:

● Be careful when using SOA when the service interface is unknown. The service interface allows the user and the provider to make changes independently, but the interface itself must be stable. Interface changes in SOA are much more complex than individual applications (especially non-distributed applications), because many unrelated development teams must cooperate on interface changes in other cases.

● When security is critical, be careful when using SOA. Each service is a new vulnerable point, and its security must be ensured. The more people who can access the service easily (such as services on the public Internet), the more people who can try to attack the service.

● When performance is critical, be careful when using SOA. Each service call between processes is much slower than the method in the process.

● Be careful when using SOA to ensure high availability of functions. As pointed out, redundant services can improve reliability, but at the same time, the more active parts, the higher the possibility of failure. SOA applications are only as reliable as services.