Without a doubt, Service-Oriented Architecture (SOA) is rapidly becoming the most popular trend in enterprise computing. Every week (if not every day), the IT department is criticized by manufacturers' publicity and Market News. vendors claim that they can provide a large number of technical and service products, it is used to magically transform the way businesses are carried out.
At the same time, service orientation is becoming more and more widely accepted, and SOA, as an enterprise computing method, is fundamentally changing the way enterprises view their IT infrastructure. Use flexible applications built based on public servicesProgramTo replace complex single-chip applications, you can increase the productivity of developers, provide more flexibility, and ultimately reduce costs. Web services and SOA can also eliminate the complexity and integration problems in enterprise application development projects.
However, like any large project with great potential, the IT department must develop the right plan and prepare the right resources to ensure successful conversion of their computing infrastructure. The biggest obstacle facing most IT enterprises is not whether to switch to SOA, but to determine the best way to do this and the appropriate investment level. Define a service-oriented architecture
Service-Oriented Architecture (SOA) is a blueprint that guides you through the creation and use of all aspects of a service throughout its lifecycle (from conception to withdrawal ), and define and provide such an IT infrastructure that allows different applications to exchange data and participate in business processes, regardless of the operating system or Programming Language What is it. With the emergence of Web Services, it has become easier to do so without relying on any specific method (data-oriented, message-oriented, object-oriented, process-oriented, etc ).
The primary goal of any SOA is to help it capability and business goals reach an agreement. Migration to SOA helps enterprises streamline the design and development of solutions, make collaboration between remote teams easier, and support reuse through module reconfiguration and redefinition of goals.
First, SOA is a way to build it systems; it is not a technology or a silver bullet solution. SOA is a methodology in which business services (services provided by enterprises to customers, users, citizens, partners, and other enterprises) it is the main organizational principle to help IT systems and business services reach an agreement. Most importantly, the way services are defined is independent of the underlying technology. On the contrary, early building of IT systems relies on specific methods, such as object-oriented, process-oriented, and message-oriented, which will lead to systems and specific technologies (such as CICs, IMs, CORBA, J2EE, COM/DCOM and so on). Therefore, it is less universal to the business. Development Based on these methods and approaches usually results in single-chip and silo applications, which can be found in most today's IT systems.
By enabling technology to adapt naturally to people who need it, rather than focusing on the technology itself (as in the previous generation of IT systems, this forces people to adapt to technology ), web service-oriented services reduce the cost of enterprise integration projects and improve the project success rate. The biggest difference between service-oriented integration and other methods is that service-oriented allows you to focus more on the description of business problems, other methods require you to devote more energy to using specific technologies to solve specific integration problems.
According to the definition, technology-oriented methods are limited to one product or technology. The service-oriented method for using web services is not based on a technology, technology type, or product, but based on the design and deployment of services that can be executed on any technical type. Therefore, developers of service integration projects can focus on business issues rather than technical issues, because Web services can be widely used as interfaces of almost any consistent technical type. You can still select the appropriate technology for the execution environment, but for service users, the execution environment technology has nothing to do with them, because they need to deal with the Web service description, rather than the execution environment.
1. As shown in, the ultimate goal of designing, developing, and implementing SOA is to provide a better update method for interactions between applications, integration with business process engines and various client types. The diamond on the bar represents the Web service interface. You can use a programming language (such as Java) to develop it from the beginning, or use the web service infrastructure product for renovation. After development, you can use common SOA services to transmit and access these Web Services. Any new application or client that wishes to use the service obtains the description from the service library. Business Process engines (usually called orchestration engines) can also access them after designing and developing web services as automatic streams. Figure 1
Businesses that use web services to successfully implement service-oriented integration methods usually have a competitive advantage over those that are not successfully implemented, because compared with those that rely on a specific technology, services that are consistent with the strategic IT business goals can quickly respond to changing business needs.
The concept of SOA is not new, but the novelty of web services lies in the ability to mix and match execution environments, separating service interfaces from execution technologies, allow the IT department to select the best execution environment for each task (new or existing application) and try to combine them using a consistent architecture approach. Implement SOA
Once you decide how to turn the IT system to service-oriented and use SOA in Web Services, You need to determine the best way to achieve this goal. Even if you are an expert in WebLogic/J2EE, Web services are still the best way to implement SOA, because they are based on a set of technical standards, these standards are independent of any specific software domain, development process, or design method. Therefore, Web services have the potential to fundamentally expand the application scope of the Weblogic Platform.
BEA WebLogic can be easily used as a design center and used to develop newCode. It can also be used to combine different existing systems using Web Services. When existing systems are exposed through web service interfaces, they can be easily combined into powerful business flow and new applications.
Web services can be applied in various ways to solve many problems. SOA brings about architectural prospects, development guidelines, and design methods. They all increase the possibility of applying web services in a strategic manner and increasing long-term value for enterprises through flexibility and reuse.
Figure 2 illustrates the unique advantages of using SOA in Web services that access the same application through multiple channels. In this example, an existing customer service application is a Web service, which is enabled using an infrastructure product, account Management Personnel's mobile phone, customer's mobile devices, Customer Service Management Personnel's laptop, call center operator's PC and reseller's service applications, it is accessed as a reusable service. Using Weblogic in combination with programs that support web services (such as Atrix) can extend the application scope of existing applications to new applications and devices. Web services help increase flexibility because they can be designed and reused across multiple business processes so that anyone can access them anytime, anywhere using any device. Web services can be reused when Web services are designed and implemented based on persistent business themes, rather than tightly coupled with specific implementations. Figure 2
long-term value
when you can completely or almost completely develop new applications by breaking down existing services, the actual value of SOA comes from the later stages of deployment. When new applications can be assembled outside the existing set of reusable services, the best value of work can be achieved (that is, results can be obtained at the minimum cost and time ). However, it may take some time to achieve this and invest heavily in service development.
more likely, some reusable business services (such as order items, checking credit card authorization, process list, and so on) and some (the number may be smaller than the former) A custom service especially developed for applications (such as helping customers decide to purchase cheap books) to build new applications. The on-site experience of the company's customers using SOA in CORBA shows that the degree of reuse can reach 70%, and the degree of reuse of Web Services in the industry may be equal to or higher than that of the former.
in general, it is easy to understand the advantages of reusing common business services, such as customer name search, zip code verification, or credit check. In a development environment that is called for each service, these functions can be executed by reusable code libraries or objects loaded/linked to and reused in new applications (although repeated ). In SOA-based applications, typical system functions such as security check, transaction coordination, and audit are implemented using external services. Using services outside the application can not only reduce the number of codes to be deployed, but also centralize deployed code and manage access to it, it can also reduce the burden of management, maintenance and support. A New Development Method
As many readers are familiar with, the software industry has widely adopted service-oriented development models as the best way to utilize Web service functions in application integration. However, it should be clear that for the previous object-oriented, process-oriented, message-oriented, and database-oriented model, service-oriented development is actually a new method to supplement them. Service-Oriented Architecture is no longer a new thing, but it is a new thing as an abstract web service layer of any executable software system. Therefore, when a service-oriented application is mapped to any or all of the previous unified service abstractions of these technologies, it emerged as an important new development model that needs to be understood and adopted.
Development services are different from development objects. A service is defined by the data it shares with messages exchanged with other services, rather than the definition of common methods/Parameter Signatures. The abstract level of the definition service must be higher than that of the definition object (some may say it is at the lowest level), because the service definition is mapped to a process-oriented language, for example, COBOL, PL/I, or message queuing systems, such as JMS or MSMQ, except for Object-Oriented systems. Because Web services need to be able to operate across all these technical domains, its development requires some research or new ways of thinking.
On the Development end, you must understand the granularity of defined services. A Web service usually requires an interface with a higher granularity that receives more data than an object in a single call. However, with the help of web services, you can create a web service aggregation so that published web services can encapsulate multiple other Web Services. This allows a coarse-grained interface to be divided into multiple fine-grained services. Coarse-grained services may be more meaningful during release, while fine-grained services are more meaningful as "private" Web services that can only be called by coarse-grained Web Services.
Figure 3 illustrates another major advantage of using Web Services for SOA: the ability to create a composite application. The Weblogic Platform is displayed on the left of the graph and can be used to access the Web Services on the right of the graph. These web services represent a mixture of services developed using new Java code and those developed using other technologies. The customer Record Service discloses two services composed of other services. Figure 3
At the project level, architects must look at the global development of reusable services and provide a method for saving, managing, and obtaining services as and wherever they are needed. Reusable service layers isolate business operations, such as "acquiring customers" or "placing orders" from various underlying software platforms, just as web servers and browsers isolate WWW from various operating systems and programming languages. Reusable services can be broken down into large services. What brings to enterprises is the advantages of process automation and the flexibility to respond to changing situations in a timely manner. Develop SOA
Developing an easy-to-understand, managed, and deployed SOA object based on Web Services must be divided into two stages. The central task in these two phases is to identify the service, and these services must be:
- Developed using the new execution environment: requires the development of new application logic in the form of Java classes and ejbs to run in the WebLogic application server container.
- To support existing application logic: you must use a tool set that is suitable for existing technologies and supports Web Services. You must either use web service calls for direct integration or use WebLogic Integration Server for indirect integration, or use both.
To include all web service endpoints in SOA, you may need to use a tool combination. For example, Iona artix can be used to enable Web Services for tibco, MQSeries, CICs, IMs, CORBA, and other existing systems and integrate with the new logic developed using weblogic. In addition, Web Service functions can exist in the updated versions of these products, and the existing applications can be published or enabled by installing or upgrading existing software to an updated version that supports Web Services, and then use them, which makes sense. However, this method is very fragile because multiple Web Service implementations may be incompatible with each other and the complexity of managing multiple web service products.
You can obtain a variety of tools that support web services through independent vendors and open-source projects. Therefore, in your SOA implementation, a major decision is to process the technical combinations to be involved. In an enterprise-wide SOA project, it is often the case that several different, usually different technologies are used to provide different service quality.
In the process of developing services for SOA, you must first decide that you need services, and then design the services to be compatible with other services you are developing. In addition, as shown in figure 4, you have to decide what you need in the additional service quality requirements for reliability, security, and transactions. It is necessary to check the Web service products you are using to ensure compatibility not only on the basic soap and WSDL layers, in addition, these extensions are compatible at the level. Figure 4
The starting point of service-oriented development is to identify the data to be shared. This becomes the XML schema representation of the Data Type and structure to be included in the message. Web Services provide two basic interaction methods:
- Document-oriented: a message is constructed as a "plain text" XML document (in other words, the data format is only meaningful to XML ).
- RPC-oriented: a message is constructed as a series of parameters to be passed to an object or process method, which usually matches the data type and structure.
In the first interaction mode, messages are generally used to transmit business documents, such as purchase orders, invoices, and tickets. This type of interaction is compatible with the synchronous Message Queuing System, such as MQ series, MSMQ, JMS, tibco, and IMS. It is usually used for business-to-business transactions, because such transactions rely on exchanging a large amount of data that may take several hours or days to process in the execution stream at a time, this will cause executed documents or new documents to be sent back to the initiator. This method is also the most abstract because it does not contain any description related to the signature used to map messages in the execution environment. On the other hand, the RPC-oriented approach assumes that the data in a message is executed by a process or object with a defined interface, the xml rpc-oriented format in messages is used to make it easier to map to or map out such existing structures.
however, the same task can be completed in multiple ways just like any other aspect of computing. Most of the problems originated from the interoperability of various web service tool sets and products are caused by incompatibility when ing complex data types and structures (such as arrays, records, and structures. In other words, the simpler the data type, the more likely you are to implement interoperability.
As a rule, the higher the compatibility of web service products, the wider their application scope. For example, WS-interoperability basic profile recommends the encoding style of documents and text (that is, the XML schema data type and structure of plain text ), instead of the soap encoding style (that is, to fundamentally define new data types and structures that are incompatible with the existing RPC-oriented technology ). Document-oriented interaction is more abstract than RPC-oriented, because the soap processor and XML Parser extract the data of interest to the application and pass it to the queue or object. When the message data has been formatted for RPC, the type of the parameter is essential for decoding and understanding the message.
in the process of designing and developing any SOA, an essential step is to find out the requirements for extended technologies. WS-Security, WS-reliablemessaging, and WS-transactions have been defined in other specifications to address this requirement, but they are used in Weblogic and other Web Service tools, the availability of the web service interfaces of existing products is very limited, and the interoperability between cross-scaling feature sets is also the case. The more extended features you use, the more difficult it is to implement interoperability. challenges
SOA-based integration provides a consistent way to access all applications within and possibly outside the company. The challenge represented by implementing SOA is that some applications may need to be modified so that they can be involved in SOA. In addition, it is difficult to accurately define reusable services for the first time.
the biggest obstacle to SOA adoption is often the fact that adequate personnel training and long-term investments are required to achieve SOA. Any technology, no matter how promising it is, may be abused or misused. We must focus on the long-term interests to develop services, rather than simply taking immediate interests into account. Unlike an object or database, the Development Service aims to allow customers to use it, but may not know this at the time. In other words, the existence of a separate service does not have great value unless it is part of a large set of services that can be consumed by multiple applications, besides this set, you can assemble multiple new applications. Any service set requires control, design, and architecture, because they are often not developed at the same time.
the main challenge for turning to SOA is the short-term management cost. Building an SOA is not cheap; Restructuring an existing system requires money, and over time, the return will become larger and larger. It requires business analysts to define business processes, system architects to standardize processes, software engineers to develop new code, and project managers to manage all the above work.
of course, when a service can be used to solve strategic problems first, it can gradually offset these costs by adopting and using it where SOA has the greatest business impact. Therefore, part of the work of using Web Services and SOA is not only to identify projects that return value quickly by quickly solving problems (such as integrating J2EE and.. NET Framework applications), and to lay a good foundation for the future strategic value through reuse, such as creating a new order item application more quickly, because it can reuse services for credit check and accounting.
another challenge for implementing SOA is that the current applications are tightly coupled, while the underlying SOA technology is loosely coupled. Therefore, in the existing environment of tightly coupled business-critical applications, it is impossible-at least not in a cost-effective manner-to achieve perfect loose coupling immediately. It may be necessary to start from a fine-grained, tightly coupled web service to meet the needs of real-time projects, but this should only be carried out throughout the long-term planning environment, it encapsulates coarse-grained services for development. Conclusion
Therefore, if you want to build SOA Based on Web Services in the Weblogic environment, and this is a task that you and your IT department are facing, congratulations, you can complete this task. With the correct expectations, strategies, planning, and implementation, you can now start to let your enterprise turn to use this computing technology to achieve Gratifying results in the present and future. It is important to consider the differences between the two Web services that require new Java code and that expose existing application functions. The combination of Weblogic and Enterprise Web service infrastructure products can help expand the application scope of Weblogic-based SOA projects. The specific method is to process web services more easily based on existing application code, whether on a large host, UNIX, or an existing Middleware system.
