Introduction to SOA

Introduction to SOA

What is a Service-Oriented Architecture (SOA )?
Service-Oriented Architecture (SOA) is a component model that describes different functional units (called services) of an application) use the well-defined interfaces and contracts between these services. Interfaces are defined in a neutral way. They should be independent of the hardware platform, operating system, and programming language that implements services. This allows services built on various systems to interact in a unified and universal manner.
This neutral interface definition (not forcibly bound to a specific implementation) is called the loose coupling between services. The benefit of loosely coupled systems is its flexibility. The other is that when the internal structure and implementation of each service that makes up the entire application change gradually, it can continue to exist. In contrast, tight coupling means that interfaces between different components of an application are closely linked with their functions and structures. Therefore, when some or all applications need to be modified, they are very fragile.
The demand for loosely coupled systems comes from the need for business applications to become more flexible based on business changes to adapt to changing environments, for example, the policy, business level, business focus, partnerships, industry status, and other business-related factors that often change may even affect the nature of the business. We call a business that can flexibly adapt to environment changes as an on-demand business, you can make necessary changes to the way tasks are completed or executed.
Although the service-oriented architecture is not a new thing, it is an alternative model of a more traditional object-oriented model. The object-oriented model is tightly coupled and has existed for more than 20 years. Although SOA-based systems do not rule out the use of object-oriented design to build a single service, the overall design is service-oriented. Because it takes into account the objects in the system, although SOA is object-based, as a whole, it is not object-oriented. The difference lies in the interface itself. A typical example of a SOA system prototype is the Common Object Request Broker Architecture (CORBA), which has been around for a long time. Its definition is similar to that of SOA.
However, the current SOA is already different because it depends on some updates that are based on the Extensible Markup Language (XML. You can use an XML-based language (Web Service Description Language, Web Services Definition Language, and WSDL) to describe an interface. The service has been transferred to a more dynamic and flexible interface system, the Interface Definition Language (IDL) is not comparable to the interface Description Language (UML) in the previous section.
Web services are not the only way to implement SOA. The same way is to use the message-oriented middleware (message-oriented middleware) system, such as IBM MQSeries. However, to create an architecture model, you do not only need service descriptions. You need to define how the entire application executes its workflow between services. In particular, you need to find the conversion point between the business operations and the operations of the software used in the business. Therefore, SOA should be able to link business processes with their technical processes and map the relationships between them. For example, payment to a supplier is a commercial process, while updating your part database to include the newly supplied goods is a technical process. Therefore, workflows can also play an important role in SOA design.
In addition, a dynamic business workflow can include operations between departments, or even operations performed with external partners not under your control. Therefore, to improve efficiency, You need to define how to know the relationship between services. Such policies are usually in the form of service-level agreements and operational policies.
Finally, all of these must be in a trusted and reliable environment to implement the process in accordance with the agreed terms as expected. Therefore, secure, trusted, and reliable message transmission should play an important role in any SOA.
What can I do with a service-oriented architecture?
The need for SOA comes from the need to make the business IT system more flexible to adapt to changes in the business. By allowing strongly defined relationships and flexible specific implementations, IT systems can utilize the functions of existing systems and prepare for future changes to meet the interaction needs between systems.
The following is a specific example. A clothing retail organization has 500 international chain stores, and they often need to change their designs to catch up with fashion trends. This may mean not only changing the style and color, but also changing the fabric, manufacturer, and deliverables. If the system between the retailer and the manufacturer is incompatible, the replacement from one supplier to another may be a very complicated software process. By using the flexibility of the WSDL interface in terms of operation, every company can maintain their existing systems as they are, instead of simply matching the WSDL interface and developing a new service level agreement, in this way, you do not have to completely rebuild their software systems. This is a change in the business level, that is, they change partners, and all business operations remain unchanged. Here, the business interface can be slightly changed, but internal operations do not need to be changed. The only reason for doing so is to work with external partners.
Another form is internal changes. In this change, the retail organization now decides that it will also rent some places in the store of chain stores to small stores that sell popular clothes, this can be seen as a business model using a store-in-store. Although most of the company's business operations remain unchanged, they now need new internal software to handle such rental arrangements. While internal software systems can withstand comprehensive overhaul, they need to do so without having a major impact on interaction with existing supplier systems. In this case, the SOA model remains intact, but the internal implementation changes. Although new aspects can be added to the SOA model to add the responsibilities of the new lease arrangement, the normal retail management system continues as usual.
To continue the concept of internal changes, IT managers may find that new software configurations can be used in another way, such as renting and pasting posters for advertising purposes. Here, the new business proposal is derived from reusing the flexible SOA model in the new design. This is a new achievement from the SOA model and a new opportunity, which may not be available in the past.
Vertical changes are also possible. In this change, retailers have completely changed from selling their own clothing to renting places through shop-in-shop models. If vertical changes start completely from the bottom layer, a significant change in the structure of the SOA model may occur, with which new systems, software, processes, and relationships may change. In this case, the benefit of the SOA model is that it considers issues from the perspective of business operations and processes, rather than from the perspective of applications and programming, this allows business management to clearly determine what needs to be added, modified, or deleted based on business operations. The software system can then be constructed into a suitable way for business processing, rather than other methods that are often seen on many existing software platforms.
As you can see, changes and the ability of SOA systems to adapt to changes are the most important part here. For developers, such changes may occur both within the scope of their work and beyond the scope of their work, it depends on whether there are changes that need to know how interfaces are defined and how they interact with each other. Unlike developers, the role of architects is to make significant changes to the SOA model. This division of labor allows developers to concentrate on creating functional units as service definition, while architects and modelers concentrate on how to properly organize these units. This method has been used for more than a decade. It is generally described as a model-driven architecture (MDA) using the Universal Modeling Language (UML ).

What is the technology that constitutes SOA?
SOA itself should be an abstract concept of "how to organize software together. It relies on more specific concepts and technologies that are implemented using XML and web services and exist in the form of software. In addition, it also requires security, policy management, reliable message delivery, and support from the accounting system to work effectively. You can also further improve it through distributed transaction processing and distributed software status management.
The difference between SOA services and web services lies in design. The SOA concept does not define exactly how services interact, but just how services understand and interact. The difference is the difference between the strategy that defines how to execute the process and the tactics that execute the process. On the other hand, there are specific guiding principles for the Web service to transmit messages between services that require interaction. The most common way to implement SOA models is to transmit soap messages through HTTP. Therefore, in essence, Web services are one of the specific ways to implement SOA.
Although we feel that Web services are the best way to implement SOA, SOA is not limited to Web Services. Other protocols that use WSDL to directly implement service interfaces and communicate through XML messages can also be included in SOA. As pointed out elsewhere, the MQ systems of CORBA and IBM can also participate in SOA by using new features that can process WSDL. If two services need to exchange data, they also need to use the same message transmission protocol, but the data interface allows the same information exchange.
A new software object is added to the framework of the SOA architecture to establish proper control of all such information, as well as application security, policy, reliability, and accounting requirements. This object is the Enterprise Service Bus (ESB). It uses many possible message passing protocols for proper control and transmission of streams or even all messages between services. Although ESB is not absolutely necessary, it is essential to correctly manage your business processes in SOA. The ESB itself can be a single engine, or even a distributed system composed of many same-level and lower-level ESB, which work together to maintain the running of the SOA system. In terms of concept, it evolved from the storage and forwarding mechanism established by computer science concepts such as message queue and distributed transaction computing.
From the perspective of developers, the tools they use must be aware of the capabilities of SOA and allow developers to effectively use SOA objects. This includes the process of designing SOA models, developing services and service objects, and testing SOA applications, and forming a whole. Therefore, developers must be prepared for service-oriented application design/Development (Soad.

What is the relationship between SOA and other technologies?
SOA can be used together with many other technologies. However, component encapsulation and aggregation play an important role in it. As mentioned above, SOA can be a simple object, complex object, object set, process containing many objects, and process containing other processes, it can even be the overall set of applications that output a single result. In addition to services, it can be considered a single entity, but in itself, it can have any level of complexity (if necessary ). For performance considerations, most SOA services do not fall to the granularity of a single object and are more suitable for large and medium-sized components.
Apart from XML and WSDL, SOA is not language-specific. You can use any programming language to implement services, as long as this programming language can generate services and can be used together with WSDL. Soap itself is not absolutely needed, but it is a general messaging system. Therefore, you can use almost any programming language and a platform that supports WSDL to implement Membership Services in SOA.
Applications Based on Common Object Broker Request Architecture (CORBA) have many components that must be connected to SOA. Although the Interface Description Language (IDL) in CORBA is similar to WSDL in concept, it is not strict. Therefore, you need to map it to WSDL first. In addition, more advanced SOA protocols (such as those used for process and policy management) are required, rather than similar concepts in CORBA. Remember that this is a situation where the CORBA Component (represented as a service) needs to interact with the SOA service; in the CORBA model, all the independent subsets can still work as before.
Object Management Group (OMG) the model-driven architecture proposed and implemented in many IBM Rational products is highly relevant to the concept of SOA at a more abstract level. Based on this concept, any software process can be defined as a model or even a meta-model (that is, a model), and then these models and meta-models can be converted into actual components of the application. Therefore, MDA creates a model, which is first compiled into a software application, and then compiled into an executable program, so that it can run on the platform. MDA does not distinguish between services and objects. However, it does allow models to be composed of other subset models, similar to the process aggregation concept in SOA (a core component of SOA.
SOA and Web services are independent of programming languages, but Java is one of the main development languages. You can use well-defined Java interfaces and a variety of protocols for Java implementation to provide an advantage for developers who are building this model. Java is responsible for developing functions of each service, managing data objects, and interacting with other objects logically encapsulated in the service.
Another important relationship between SOA and web is the concept of autonomous computing and grid computing. The concept of autonomous computing is used to manage the scope of the distributed service architecture. Specifically, it helps maintain the overall stability of policies, service-level protocols, and SOA systems.
In addition, grid computing can be used with SOA systems at two levels. Grid is a form of distributed computing. It uses distributed features and interactions between services to provide computing support for SOA applications. In this case, the grid plays a role in the Framework, which implements some or all of the individual services. Therefore, SOA applications can be consumers of grid services.
On the other hand, the mesh itself can also be built on SOA. In this case, each operating system service is a member of the entire SOA application, and the SOA application is the grid itself. Therefore, individual grid components can communicate with each other using Web Services and interact with each other using SOA. In short, a grid system can be an SOA, or provide services to build an application-level SOA model on it.

How to build an SOA system?
The advantage of using SOA is not only that it is a software development process, but also a business development process. There are four layers of SOA. Your implementation can span from creating a specific software service to fully transforming your business model to an on-demand system.
The first layer is the simplest, because it only needs to create a separate service.
At the second level, you can not only create services, but also integrate business functions into SOA. This involves multiple layers of integration, including application integration, information integration, process integration, and integration of the entire system.
The third layer involves converting your enterprise IT infrastructure to the SOA model, while the fourth layer of SOA focuses on transforming your business model to make it an on-demand model.
From the perspective of IT professionals (compared with the business layer), to create SOA applications, you usually go through four phases: Building, deploying, using, and managing. During the build phase, you can define business models or processes, software models, and SOA models. Then, you can create a group of services that can be reused with published universal interfaces.
In the deployment phase, you extract the created services and place them in an executable and manageable environment. In the use phase, you assemble an application based on the SOA and software model mentioned earlier, and test its software quality and non-functional requirements, such as performance and scalability. The application is now ready for delivery to users. The last management phase is a long-term process in which you can monitor and manage security and usage, and compare the performance in many aspects that correspond to service-level agreements or policies that you may have developed for SOA.
These are the conceptual stages of the SOA lifecycle. Many roles need to be added to the creation of SOA applications in order to embody the actual working roles corresponding to these stages. These roles may engage in the same job, or cross-team members or even multiple teams. Roles defined in Rational Unified Process (RUP) Express the concept of roles very well.

How can I improve my SOA skills?
Skill acquisition depends on the type of professional: Information Analyst, software architect, software developer, software quality analyst, system administrator, etc. As mentioned above, the concept of SOA spans all these work roles. Therefore, it is very helpful to understand the role of each role.
Next, you should be familiar with the technical concepts included in each role. Information Analysts and software architects should be familiar with model-driven architecture (MDA) and UML 2.0. Software developers and programmers should understand the programmatic interfaces of Web Services, MQ and other protocols, the way interactions are protected programmatically, and the concept of workflow processing. Quality analysts and System Administrators should understand the implementation of the SOA process model and the actual SOA functional architecture, and how developing separate services separately affects the overall performance of such distributed applications. The system administrator should also know how the application security and trust model work, and how the application policies affect the operating system platform and network system.

What tools and products can IBM use for SOA?
IBM is the first large vendor to provide a comprehensive set of tools, training, and service routes for building and deploying SOA-based IT systems. They cover all aspects of the SOA lifecycle, including the tools used for building, deploying, using, and managing services at all levels of SOA. Each layer includes lower adoption layers and tools. Because the process can be expanded, it is not necessary to use all the lifecycle stages at each level. Finally, the fourth layer of on-demand business transformation is the business-oriented level rather than the technical process, and the same software at a lower level is required.
In the first SOA adoption level for implementing individual web services, the tool shown in Figure 1 is mainly used to help developers create and operate simple web services.
At the second level, service-oriented integration (service-oriented integration) provides tools to discover and interact with multiple services, as well as the basis for creating SOA models. Figure 2a shows the core components used by Level 2, while Figure 2b shows additional components that can help level 2.
In Level 3, it transformation within the enterprise scope, IBM provides a variety of SOA and Web Services ready-to-use products, so as to support all IT system functions, it also provides enterprise-wide management of SOA systems. Figure 3A shows the Core Components in Level 2, while Figure 3b shows the additional components.