Author: Rag Ramanathan
Limited reusability, multiple data formats, tight coupling, and many other problems hinder the integration of applications, but SOA can change this. Application integration is one of the most critical issues facing enterprise information technology managers. The company uses many customized and existing packaged applications to run their business processes. These applications must integrate to achieve information sharing and create new applications. Traditional application development and integration methods do not have flexibility and are not based on standards; therefore, they do not have a driving role in providing a flexible enterprise IT environment that supports dynamic organization's changing demand. Development and integration In large enterprises, applications must be able to interact with business data from one or more data sources, some of which may be other applications. In other words, there is no integration without the development of applications. On the other hand, the application's integration requires a certain application development task, such as development and assembly components, connect components to the backend system, implement flow flow and workflow, develop user interface, and debugging. The practice of considering the development of the application and the integration of the application is outdated, and there is no benefit. With the development of application development and integration methodology, IT now can have followed business rapid growth and changes. However, the speed of technology updates is behind the speed of business changes. In most companies, the lack of flexibility in IT sectors hinders that companies make real-time changes in the needs of customers. The three most common methodology of application integration is the integration of point-to-point, enterprise messaging bus, or middleware integration (ie, EAI), and based on business processes. In integrated methodology of point-to-point point, the application integrates as needed (see Figure 1). The interconnections shown in the figures can also be built with a web service. This does not allow it to become a SOA-based system because it lacks other features such as loose coupling, one intermediate basis, and shared infrastructure. Figure 1. In the integrated integration of typical point-to-point, each link is a private API and protocol. No web services are used. Since the integrated method of point-to-point is very complicated, the cost is high, and it is difficult to maintain, and another integrated method is introduced. This method is called enterprise application integration (EAI), which is based on a messaging bus / agent or middleware. In this case, the connection between the application and the message bus is implemented with a private bus API and an application API (see Figure 2). Figure 2. Enterprise Application Integration (EAI) based on the message bus / agent or middleware. EAI is improved based on business processes. In this case, the business process flow engine is used to run the flow flow with the message bus or the middleware, which performs multi-step transaction processing of different systems. Disadvantages: There is no ideal in these traditional integration methods (see Figure 3). Existence includes: Figure 3. Three most common methodology of application integration is the integration of point-to-point, enterprise messaging bus, or middleware integration (ie, EAI), and business-based integration. However, these methods are not ideal.
Custom or private integration between messaging bus and application. Compared with the point-to-point integrated method, EAI and business-based integration methods reduce the number of integration points. However, these three methods require custom or private integration between messaging bus and each application, and each integration point contains different and private data formats. Tight coupling between messaging buss and applications. All applications require an internal work mode of other applications integrated with it. The integration between the system is granulated and is tightly coupled through the message type. The business process management tool used in traditional EAI implementations is private. This hinders the application of the best product. Documentation rather than abstract data access. The challenges of access, integration, and conversion data (enterprise information integration) are mainly implemented by developers through manual coding. The existence of different data sources is a realistic situation in the enterprise IT environment. Developers use adapters to access data sources, reformat data with the conversion engine and use replication to physically reinforce data. To integrate data sources, developers will use these tools to encrypt integration requirements into applications. Although this method works, it is inefficient and has no flexibility because of the following: lack of abstraction. Programmaker must use the low-level API to achieve integration needs, which greatly adds development and maintenance costs. Multi-numerical format. Each data source has its own API and data format. Developers must learn more about each data source to manage data integration. This often requires multiple experts to achieve and maintain integration, and the results have increased complexity and cost. Customize the information integration framework. Developers must handle all integration issues, such as relationships between data sources and data formats. This leads to a one-time solution and inconsistency that is difficult to maintain. Tight coupling. Programming causes hard coding dependencies between applications and data sources. The update of the data source will interrupt a number of applications, which is not conducive to maintenance. Limited reuse. Integrated codes are often dedicated to each application and data source, which makes it difficult to reuse. Why choose SOA? All three traditional application integration methods are complicated, high cost, and do not have flexibility. In addition, they do not support the needs of business changes. However, the development and integration of applications-oriented architecture (SOA) is developed and integrated to solve many of these problems. A set of standard interactive mode defined by SOA allows consumer applications to utilize services. These methods define how to describe services, how to advertise and how to discover services for services, and how to communicate with services. In SOA, different from the previous method is that all modes around the service are implemented using standard technologies. Most communication middleware systems, such as remote procedure calls (RPCs), public objects Request Agent Structure (CORBA), Distributed Component Object Model (DCOM), Enterprise JavaBean (EJB), and Remote Method Call (RMI) Similar models. No implementation is perfect, the problem exists in interoperability and defining standards that can be accepted. SOA attempts to eliminate these weaknesses. For example, each middleware system has a fixed particle size: RPC function, CORBA object, and more. However, services can be defined as functions, objects, applications, or others. This allows SOA applicable to any existing system and does not force these systems to meet the particle size of any particular level. SOA helps information system to move to a "Leave-Layer" architecture that is not to change existing systems to provide a standard-based service interface, which is packaged into one layer, provided by this layer. Service interface. The web service is a way to achieve this layer. SOA is not replacing an existing architecture, but converts existing systems and applications into flexible services. SOA includes information from packaging applications, custom applications, and legacy systems, but also features and data from IT infrastructure such as security, content management, and search.
SOA-based applications is fast, because they can make it easy to add features from these infrastructure services. Figure 4 shows an advanced view of an enterprise application using a service-based integrated method, which is similar to the structure shown in Figure 2. However, the key to the critical is that this system uses a standard service and contains process / data services, orchestration, and composition. Standard-based services have become integrated points between applications. Orchestration and synthesis (Composition) adds integration of flexibility, reusability, and service. Figure 4. Architecture of an enterprise application using a service-based integrated method is similar to the architecture shown in Figure 2, but this system uses a standard service and includes process / data services, arrangement, and synthesis. Now, you have a brief understanding of SOA, let us discuss SOA, see how it makes integration easy. SOA Design SOA allows companies to concentrate on business processes during their application, rather than paying attention to low-level issues related to integration or applications. SOA is a collection of reusable network services that communicate with good, and platform independent interfaces. These services provide access to data, business processes, and IT infrastructure and allow management of service providers, consumption, and lifecycle. Table 1 highlights the difference between the distributed component architecture and the SOA. SOA provides the advantages of many traditional methods; these advantages are based on standards. Loosely coupled. For sharing services. Rough granularity. Die-oriented control.
Distributed component architecture
Service-oriented architecture
Functionally-oriented process-oriented persistent design variation design longer development cycle interactive and iterative development with cost-centric business-oriented application block service to tightly couple flexible and adaptive Structure heterogeneous technology is subject to object-oriented messages known to implement abstract table 1 distributed architecture and facing service architectures. SOA-based solution requires a set of specific features from the SOA infrastructure; these features are listed in Table 2, and the properties required to manage and support the SOA infrastructure are also listed.
Characteristics
description
Advantages, application performance and annotation
Loose coupling service providers and consumers can develop independently with a well-defined interface. Service implementors can change interfaces, data, or message versions in the service, and do not affect consumers. Loose coupling eliminates the need for tight control on both ends of the system. Each system can achieve independent management on the performance, scalability, and high availability of the system. It does not eliminate any runtime dependence. It can divide the dependence of many service providers, but if the runtime requires 24x7 availability and the throughput of 50000 per second, then these needs of the service provider must be met. Implementation changes are hidden. Loose coupling provides independence to service providers and consumers, but requires standard interface and intermediate to actively manage and request requests between terminal systems. Industry-based standard real industry standards are recognized by technology flagship such as BEA, IBM, Microsoft, Sun, Oracle, W3C, and Oasis. SOA is widely accepted because it can be implemented in standard technology. Eliminates the need to have private customers. Use standard-based technologies to break the industry monopoly and promote the optimal combination of supplier products. The concept of loosely coupling layer depends on wide support for standards internally and external. Reusable services Since the service is published in the directory and is available throughout the network, they become more easily discovered and reused. If a service cannot be reused, it may not require a service interface at all. For different purposes, the service is again combined, and this way can also be reused. Service reuse avoids duplicate development, while improving the consistency in implementation. The reuse of the service is easier to implement than the reuse of the component or class, and the components and classes have been reused in the past, but rarely succeed. Synchronous Service Call (RPC Mode) In the synchronous service call, the caller is called, passes the required parameters, interrupts and waits for a response. If the service provider is available, the synchronization service call can be an immediate response for the request. Synchronous services are critical for applications that require real-time response, such as Portal or Query. Asynchronous service call (document mode) In an asynchronous service call, the calling direction message transceiver service sends a message containing a fully context, and the transceiver service passes the message to the recipient. The recipient processes the message and returns a response to the caller through the message bus. In the process of being processed, the call party will not be interrupted. Due to the use of coarse particle size messages and messaging services, the service request can be queued and processed in the most appropriate system speed. This approach has high scalability because the length of the queue is allowed, and the message transceiver system can queue how many requests. The caller does not keep the network connection in the process, and because the caller is not interrupted, they do not have the negative impact of the delay, nor will it be affected by the problem in the execution of asynchronous service. This implementation is supported by the callback, which is not part of the Web service standard. No interference development (by using existing software components) Existing software components can be supplied as a service as a service. The service is to define or generate with the interface interface. Eliminate the needs of modifications, test, and maintain existing software. With a combination service, features from existing investments can be reused and recombined to create new value for companies. An example is to create a WebLogic Workshop control for existing EJBs. Policy Management When the shared service is applied to the application, the rules that are unique to each application are externalized as a policy. At designing and runtime, you must have the management and application of each service. Strategy-based calculations can promote the creation of ordinary reusable services. As the specific application service is customized, the change in application implementation is reduced to the minimum. Usually implement a strategy is an organization's operation and support team, which is not a development group. If you do not use a policy, the application's developer, and the operation and support team have to implement and test the policy in parallel to shoulder in the application development process. The use of strategies enables developers to focus on application logic, and make operational and support teams focus on rules. Data Access Service Data Access, Integration, Conversion, and Reuse Services.
Hide the complexity of the data source while strengthening the consistency, integrity, and security of across data sources. Combined Services Combine Services merges new existing applications logic and transaction processing. Take advantage of existing IT investment. Suitable for green space and legacy implementation. Assembly or arranging products simplify the integration of heterogeneous systems. Shared or enterprise infrastructure services are called shared infrastructure services based on all applications built by SOA build. Use the shared infrastructure to provide public services to avoid each application to build similar services. Use shared infrastructure services provide consistency and allow single point management. Other shared services (such as security-related services) can be created by way of providing existing products as a service. Fine-grained service fine particle size service achieves the smallest function, consumes and returns minimal amount of data. The fine-grained service can be implemented in a web service, or it can be implemented using a distributed object based on RMI, .NET or CORBA. The advantage of fine-grained services is that there is a strict security and access strategy in granular level. Implementation and unit test are simple and independent of each other. Rough granular service Coarse granularity service is more functionality than fine particle size services, and consumes different quantizable structured data or messages. They return a similar data or message, which may also contain the embedded context. Rough granular services do not need to be invoked multiple times through the network to provide meaningful business functions. Table 2 The SOA-based solution requires a set of specific features from the SOA infrastructure. Here is some typical SOA features.
SOA Services Figure 5 shows three basic roles (service providers, consumers, and agents) of SOA and some of their workpieces (artifact) and operations.
Figure 5. A SOA has three basic roles: service providers, service agents, and service consumers.
Service is a software resource available on the network. Service providers provide services through standard mechanisms while serving consumers have planned consumption services through the network. The service agent releases the location where the service is located, and these services are positioned when the consumer issues a service request. The role of consumers and providers is not exclusive; the service provider can also be a consumer, and vice versa. Service providers describe their services in a service agreement and publish with a service agent. Customers queries the service agent (or registry) they need, and receive protocols and information when accessing the service. The customer or consumer is then binding the service and calling the service directly. A service has two parts: interface and implementation. The interface defines the programmatic access between consumers and providers. A service interface must contain the identity of the service, the details of the input and output data, and metadata related to the functionality of the service. This service implements the functional or business logic of the service. This implementation should be a "black box" for service consumers; consumers do not need to understand the functionality of services. There are 5 types of services, which are:
Data Access: Allows unified access to different data sources.
Components: Provide access to packaged applications, such as access to Enterprise Resource Planning (ERP).
Business: Provides complex services that use multiple packages or custom applications.
Synthesis: Create a new service using the above three types. This service contains both new features and existing features.
Shared or enterprise infrastructure services: low-level services, such as message logging, reuse quickly creates new advanced services.
Data Access Service. Data Access Services allows users to access, integrate, translate, and convert all relationships and non-relational data resources for the entire enterprise. These services typically hide direct access to resources, hide the complexity of the basic format, and hide direct conversion and manipulation of data. They provide a unified API, loosely coupled, a common data model, and reuse of consistent information throughout the app. Data Access Service is the most common in the SOA architecture, the most widely used, and is also the most easily implemented service, and the separation of data layers and application layers is usually directly very straightforward. With the extensive access and sharing of data resources, they have become the primary goal of service implementation. XML is widely used in data exchange between applications. An infrastructure that can be abstracted, unified data access, a unified data access is valuable for SOA implementation. XML Data Service (XDS) provides access, data modeling, physical data to logic data, and XML access to logic data, for multiple data resources. Component service. Component services are coarse granular services, regardless of whether these services are packaged applications (eg, enterprise resource planning [ERP], customer relationship management [CRM] or supply chain management [SCM]), they can come from a single corporate resource release. One example of component services may be "adding customers to ERP." These services are considered enough value, so they can be released directly. The method of component service implementation is to provide reusable features with each application API. These services can be implemented with distributed computing techniques (such as J2EE EJB, COM / DCOM, and CORBA). Business service. The function of the business service (provided by the business application) executes one or more business operations. Business services are typically composed of multiple business transactions of multiple applications. They can be end-to-end business processes, for example, Process New Hire, or they may need to be part of a larger service context, such as in the provision new dsl line or add new employee. Provision New DSL Line needs a larger service context, such as a part of DSL Order Process, requiring information about the process to complete its business. Combined application. Combined applications are created by combining new logic with transaction processing, existing applications are provided as a service or component service. Application Integration Technology and Business Process Management Tools play a key role in the creation of a composite application. Featured portals such as Sales Portal and Employee Portal are examples of a combined application; they require business, components, and data services. Shared or enterprise infrastructure services. The biggest value provided by SOA is that it can synthesize an application quickly with existing services. These can be called shared services, public services, or enterprise infrastructure services. Infrastructure services can be divided into four categories: shared application services
Messages and proxy services
Portal service
Shared business service
Some examples of infrastructure services are service repository, service finders, and proxy, single sign-on, content proxy, logging service, unique ID generator, data service, and security services. Service particle size. The service can be defined as fine-grained, coarse particle size or combined based on the service function and the amount of data transmitted and received. The granularity of the service has two related meanings in SOA: how much the service is implemented, as well as how much data (or how much message) is required for consumption and returning. Fine-grained services achieve minimal functions, and send and receive a small amount of data. The coarse granular service achieves a large business function and exchanges a large amount of data. The fine-grained service can be consumed by a coarse graintric service or a composite service, but it cannot be directly consumed by the terminal application. If an application is created with fine granular service, then the application will have to call multiple services over the network, each of which exchanges a small amount of data. Consumers of coarse granular services do not expose the fine-grained services they use. However, coarse granular services cannot provide a granular level security and access control because they may use multiple fine-grained services. Composite service (Composite Service) can be combined from a coarse particle size or fine grain. The distinction between coarse granular services and composite services does not depend on the amount of data. A crude granular service may be CREATE New Customer, which will need to use external services to verify the validity of the customer and create records of the customer in a CRM application. A Combined Services may be ProVision New DSL LINE, requiring service call to verify the validity of the order, create or verify the customer, check the availability of the product, and assign resources for the LINE. Advanced SOA Solution Model Enterprise Infrastructure or Shared Service adds a lot of value to SOA. Shared services are usually implemented based on its functionality and location. Figure 6 shows an advanced view of an SOA solution model that applies the features shown in Table 2. These features are implemented by shared service layers, and the shared service layer is logically packet into a number of service layers. This figure uses some applications and services developed by the BEA Information Technology team. Figure 6. Here is a advanced view of the SOA solution model.
Figure 7 launches each service layer and shows some public services in each layer; it is obvious that these services will vary depending on the company. These service examples are designed and implemented by the BEA Information Technology team.
Figure 7. Of course, each company will have different enterprise infrastructure services
SOA and Web Services SOA does not require web services, while the deployment of web services cannot produce a SOA. However, Web services is a good example of service, and it is also a component of the company SOA (not a required component). SOA provides conceptual design patterns for service-based distributed systems. Standard-based techniques provided by the Web service utilize ubiquitous communication methods, so you can implement SOA with lower cost. When the service interface is defined with the Web Service Definition Language (WSDL), the service is a web service. Before WSDL is widely accepted, the common service definition language has Corba IDL, Tuxedo FML (it is said to be a interface definition language, it is better to say data format definitions), CICOM Microsoft IDL, and CICS Common Area (Commarea). In the past, CORBA, EJB, COM / DCOM, CICS, and Tuxedo provide services based on service-based applications development and integration techniques to implement SOA. CORBA, EJB, and COM / DCO provide object-based distributed systems, which provide functions and methods for performing specific services. SOA provides an architecture that manages them for many loosely coupled services developed by Web services or other similar technologies. The implementation of the Web service can utilize J2EE-based applications, enterprise service bus (ESB), or .NET framework. WEB services based on J2EE Applications Implementing components and applications developed based on J2EE specifications (such as EJB, Servlet, and JDBC), and uses HTTP or Java Message Services (JMS) to provide them as web services (JAX-RPC) )come out. Asynchronous coarse granular Web services are implemented using the JMS service provided by the application server. In addition to pure J2EE-based Web service implementation, the BEA platform also provides additional, abstract, controlled, process-based, and web services supported by WS-ACKNOWLEDGEMENT specification. SOA and Enterprise Services Bus (ESB) ESB integrates publish / subscription messages, synchronous (RPC), and asynchronous messages, basic conversions, content-based routing, and local web service support. In addition, ESB supports numerous application servers. ESB can act as a shared message receiving layer that connects applications and other services in the entire enterprise. ESB was originally defined by Gartner analysts, which was gradually seen as a core component for service-oriented infrastructure. Adapters based on J2EE Connector Architecture (J2EE CA) are often used to integrate ESB and enterprise systems. The ESB uses intelligent conversion and route to supplement its core asynchronous messaging center, with the purpose of ensuring reliable transmission of messages. Participating in the ESB service either use the web service message to send and receive standards, either JMS. An important difference between JMS and Web services is that JMS is a Java programming API, while web services provide a standard Wire-Level protocol (based on HTTP-based SOAP). This shows that JMS does not eliminate interoperability issues related to private messaging solutions. Each JMS provider (such as WebLogic, Sonic and Fiorano) implements a private protocol between JMS customers and JMS servers. Therefore, there is no interoperability between JMS customers and servers, for example, Sonic JMS servers can only be accessed by Sonic JMS customers. The ESB itself does not provide a complete infrastructure for SOA.
For example, it is difficult or impossible to use ESB to implement application logic, components, flow logic, and workflows, but they can quickly implement and provide services through the BEA platform. For a geographically not a distributed business, it is not necessary to use ESB to implement SOA. SOA and event-driven structures (EDA) In the enterprise, the system will undergo changes in state. The event is triggered by the state change and passes the data related to the change to other systems or people. The business can benefit from handling those caused by real-time system status. For example, not to periodically check to decide whether to order goods for a warehouse, but when the number of goods is below the critical value, an event is triggered by the warehouse management system. The event can then send a alarm notification to the reserves system. According to Gartner's point of view, modern, flexible enterprise IT's basic architectural mode is a service-oriented event-driven. The event-driven architecture is a method for designing and creating an application. The messages triggered in these applications can be passed between independent, non-coupled modules, and these models do not know each other. The event source typically sends a message to the middleware or message proxy in the subscriber of the registration of the message. Since the event message is passed through the message agent published / subscription, an event may pass to multiple consumers. This is the main difference between EDA and SOA: In SOA, producers and consumers have a one-on-one relationship. In EDA, based on the subscription rules registered by the message agent, EDA event producers can finalize any quantity consumption. Pass one message. Advanced EDA implementation must support complex event processing, where multiple related events are accumulated together with policy-based rules while trigger a single business event or service. BEA's business partner ISPheres provides an example of an implementation of this feature. You can also use the BEA platform from defining build this feature. EDA and SOA are two complementary architectures. The EDA source can be a SOA consumer or server application, and EDA consumers can also be a SOA client. BEA WebLogic Integration Message Agents, Various Event Builders, and Adapters and BPMs fully capable of bundling EDA-based and SOA-based implementations. The time to use SOA is that business issues require a request / response or real-time solution, and the customer knows the service provider in advance. EDA uses the time that the service requires one-way messages to send and receive, involving long-running asynchronous flows, while the event source does not need to know who the event recipient is. SOA Applicability and Its Disadvantages SOA Use require additional design and development work and infrastructure, which can be converted to additional IT costs. Therefore, SOA is not suitable for all situations. For the following applications, SOA and Web services may not be recommended: no components or separate independent, non-distributed applications; for example, text processing applications do not require calls based on request / response.
Limited domain or short-lived application; for example, an application created as a temporary solution is not intended to provide functionality or reuse for future applications.
Requires unidirectional communication, and does not require loose coupling applications.
Sworthy application environment; for example, all applications are environments created with J2EE components. In this case, the communication based on HTTP-based XML is used to implement communication between components is not optimal, it is best to use Java remote method to call (RMI).
Need to be rich, GUI-based applications; for example, a map operating application containing many geographic data manipulation does not apply to service-based large data volume exchange.
Most of these cases do not apply to enterprise applications. SOA is a network-centric, so it needs to be complex and reviewed for services. Because the service reuse and sharing is the main feature of SOA, the number of service consumers will be a lot, which causes version control, change management, and measurement issues. The management infrastructure required for these issues may be too expensive for some projects. SOA is a strategic solution with a large number of tactical applications and benefits; however, to get the benefits of SOA, you need to span a threshold. SOA usually needs to analyze costs and benefits.
Can SOA make it easy for application integration? Just ask the managers who use SOA to be customized, commercial, and legacy applications, they will tell you. This bundle can improve the key business process of mission.
Compared to traditional integration methods, SOA provides many advantages to the organization, which can be reused, platform independent business services, based on standard development and ability to rapidly change the speed of business development.
About author
Rag Ramanathan is currently a corporate designer of the BEA Global Enterprise Advisory Group, which is primarily a BEA consultant, partner, and customer development SOA best practice guidelines, and provides SOA business value assessment. He has more than 12 years of industry experience, including more than 6 years in the BEA R & D department as a software engineer and professional service consultant. Contact emails are: soa@bea.com.
Original source:
http://www.fawcette.com/weblogicpro/2004_09/magazine/features/rramanathan/
