introduction
Organization is developing rapidly, they try to meet changes in business needs while controlling costs. This means that companies need to organize their own applications in a simple restructuring of the information system. Important organizational changes (such as the creation of mergers or subsidiaries) may also introduce new variables into the information system.
Enterprises may also need to purchase applications on the market or sign a subcontracting contract for some of their business needs (such as subscripts or back-office management). Unable to ensure that existing technical frameworks support these services.
As the information system becomes more complex, development must be simplified. This makes people have interested in Enterprise Application Integration, EAI. Enterprises still must supplement EAI with business services and access to new integrated applications.
At present, the interface-based architecture considers this growing demand for business services, flexible access and client independence. Interface-based architecture includes web services, J2C connector architecture (J2C Connector Architecture, JCA; see References for more information) and technologies such as Java Message Service, JMS. They also include all variants of command patterns that separate client code and business services. These calling frames and EAI middlemen can be called mutual.
In this article, we first discuss the main features of each interface technology, and then tell the requirements that prompted you to choose technology. After reading this article, you will understand how to locate a variety of technologies and how to choose one of them.
Features of Web services, JCA and JMS
This section lists the related interface technology and introduces some of their features in detail.
Web service web services are implementation of service-oriented architecture (SOA). SOA has a loosely coupled tripartite: provider, proxy and requestor. The service service provided by the provider means an implementation that the requester cannot see directly. The requester learned from the agent that it must be sent up from the provider and the protocol used to access the service. The requester does not understand the way the provider implements business services.
The Web service is defined as the required service interface between the requester and the provider instead of all business requests. Some variables reflect the characteristics of the Web service, including:
They can be tight, their deployment can be based on the use of the calling frame. They are executed in synchronous request / answering methods or asynchronous methods. They can be disclosed by J2EE or non-J2EE providers. They may provide support and security (or may not provide this support).
The JCAJAVA connector architecture mainly processes the need to access the business logic of Enterprise Information System (ENTERPRISE Information System, ES) in a tightly coupled manner. The connector architecture provides support for resource adaptation, and the resource adaptation brings J2EE security, transaction, and communication sharing to the corresponding EIS technology.
At first, people's intentions let connectors access old transaction servers on the mainframe in synchronous request / answer mode, which is also working in most connector. At present, the standard development direction is more asynchronous two-way connectivity.
Some user-defined variants of the connector are more mature, they run in logical connection mode. Similarly, they can be used as a calling frame to select the appropriate physical EIS target and business operations in a way similar to the web service.
JMSJMS is asynchronous, messaging-based interface. You can also use JMS to access business logic distributed in different types of systems. Message-based interface supports the following features:
Click to point and publish / subscribe mechanisms. Message-based frameworks can pass information to other applications and these programs do not have to explicitly request it. The same information can be passed in parallel to many subscribers.
Rhythtic independence. The JMS frame operates asynchronously, but also provides a function of simulated synchronization request / response. This allows the source system and the target system to run simultaneously without waiting for the other party. Have guaranteed information. The JMS framework can manage messages in a transaction mode and ensure that the message is passed (but does not ensure timely delivery).
Interoperability between different types of frames. Source applications and target applications can run in different kinds of environments without having to process communication and execution issues related to their respective frameworks.
Make the exchange more smoothly. After the message mode is changed, the fine particles of the information exchange become thinner.
Select Interface Technology
The way you have implemented business logic in the system will enable you to naturally face a technology in these technologies. The first step in making a choice is to analyze your existing infrastructure. Is there an existing message delivery system or an old system (such as CICS or IMS)?
In many cases, the most natural way to access the mainframe EIS (such as CICS or IMS) is through the Java connector architecture. On the other hand, if you need to access the .NET application, you are likely to tend to the web service interface. In other cases, you may use the JMS interface that allows the message to exchange and the constraints of the realization are small.
Please use the following decision points to the summary:
You have an existing Java app or in planning a new Java application: use JMS or JCA.
You need to interact with partners: use web services to transfer and connect.
You need an obstacle between languages: Use JMS or Web services.
When making a decision, another factor to consider is the range of the network: which is the Internet, internal network or external network? This range determines how flexibility in selecting the transfer protocol. The deployment of the Internet is likely to need a loosely coupled web services through HTTP. This will match the existing firewall and non-military zone (DMZ) infrastructure, you can minimize costs. JMS and JCA are more suitable as an internal network or an external network protocol. JMS is suitable for synchronous mode of asynchronous or simulated, and JCA is suitable for tighter coupling.
Choose common
Web services are not synonymous with services provided by SOAP. You can view the code and access protocols described in Web Services Description Language (Web Services Description Language, WSDL) with its features as a web service. You can provide any such service through multiple transfer and protocols.
Therefore, you can use WSDL-centric approach, which is described and implemented by the Web Services Invocation Framework (WSIF). Regardless of the network scope (internal network, external network or the Internet), this is associated with the choice made for integration.
You are likely to try to keep more options to future extension plans, including existing enterprise systems expand or connect to business partners. To simplify this approach, you can describe the same business components in a WSDL document, you can:
By inbound binding concept, it is available in different protocols such as SOAP and RMI-IIOP. RMI is a Java remote message call. Internet Inter-ORB Protocol, IIOP is a CORBA wired protocol. Throughbound binding concept, different types of components (such as JCA or JMS-based components) are implemented.
If you use this way, JMS and JCA are just a server provider that may be used to implement several protocols of business components. Therefore, different networks and interface technologies only affect part of non-functionality, such as security, performance, response time, and availability. When the same components on the internal network and the Internet can be used, the difference between the two networks is the required security, expected performance and requirements. WSDL-centric approach allows you to separate the abstract interface from the exact protocol stack. You can use two ways to implement this method (both methods use WSIF):
By using IBM Web Services Gateway (WSGW), existing WSDL descriptions are deployed and described in the SOAP channel. Inbound binding is SOAP, outbound binding is an existing WSDL implementation description. The existing WSDL description is consumed by using IBM WebSphere Studio Application Developer Integration Edition (WSAD-IE).
Interactive mode
When you design an application, you need to define the mode of interaction. In general, these patterns reveal your favorite preferences.
The listener of the event-driven push model waiting event provides a standard event push model that is particularly important for EAI. Automation of business processes often needs to capture application events to spread to other integrated applications.
Standard business services listeners often use JMS or HTTP servers. The message driver bean in EJB uses JMS, and the web service uses HTTP.
In this push model, the incident triggered flow. The Web Services community has made a lot of work in order to formally define this process interaction. Specifically, the Web Services Flow Language, WSFL and Web Services Business Process Performing Language (BPEL4WS) standard can handle this event sort.
In WSFL, as a response to the entry message, the process engine can perform a new process instance (in the SPAWN lifecycle operation as a flag). It provides support for the notification for the support of one-way interaction. In BPEL4WS, as a response to the entry message, the Receive or PICK activity can be implicitly launched; the PICK activity can select the running process according to one of the set of events.
Synchronous request / answer mode In the enterprise, performance requirements may prompt you to choose JCA implementation, especially when most business logic is in an existing EIS, even more. However, there is no access to all systems, in some cases, using JMS to add a message layer is the only solution.
Message delivery is not the main choice for request / response type interaction. Since the isolation of messaging, the request / response to the intermediate piece implemented by the message transmission hinders the transaction coordination between the caller and the adjuster. In addition, the caller's programming logic (not the connected connector is implemented) must manage the response timeout.
All three interface technologies (web services, JMS or even JCA) work in asynchronous mode. The request or event is sent to the target and the answer is just "message being correctly passed". It is "sending and forgetting the" fire-and-forget "interaction.
Supporting this model in the architecture is not the main problem, and the technology you use is similar to those in other models. You often pair the asynchronous models and events to push or polling mechanisms, which is likely to prompt you to choose some kind of technology. In the case of a Web service, although tools are not suitable for asynchronous interactions, this form is supported. SOAP-based web services not only support synchronous RPC interaction, but also support asynchronous messaging. Its basis is a documentation model. In this model, requesters and suppliers must process SOAP envelope formatting and analysis.
A document model is a way to real unidirectional communication.
Technical selection requirements and meanings
The next part discusses non-functional requirements for determining factors in the access technology of the service logic.
Susplaced or fastening coupling means that there is not easy to change, forced to accurately expressed, predetermined client-server or consumer-publisher relationships. In this case, for a given client, you typically have only one specific server, which is faulty (this means the technology interaction of the client must handle the error of the agreement). You can view this tight coupling at the interface definition level or protocol stack. In order to access the service, you may depend on the specific abstract definition or specific protocol stack of the service.
Loose coupled systems are often designed to address issues across the data stream boundary, and the work program only solves a part of a bigger problem, and does not necessarily know the context of this problem. You often extend these systems from the addition of more work procedures.
You can loosen them as follows:
By providing a public contract describing the relationship between consumers / clients and producers / servers, you can build and integrate your app without having to let others know the technical details of your app (and over time). Changes occurred in the passage). With the same tag, you can use other developers' public contracts to use their applications without having to know details. By providing a protocol stack with an anonymous server without connection interaction, you can use the faulty elastic mechanism to interact with the components. By providing a communication channel-independent communication channel, especially through an agent-based messaging system.
Now, we map the three techniques discussed to loose or tight coupling.
JCA is tight coupling technology.
JCA is a J2EE standard using a container to connect requests and access to the enterprise information system. The container is a coupler that provides managed mode support for security, transaction domain, connection management propagation, and interaction with the target system. The JCA coupling interface is strictly defined by the public client interface. The application components do not see system contracts and containers-component contracts, but these contracts have indeed linked the caller and the adjuster. JCA has not dealt with business issues similar to billing and auditing. Realizing these requirements is still a problem with the application business architecture.
JMS is loose coupling technology. For example, it (only to the message middleware) does not provide security or transaction binding to the target system. In general, the reasons for messaging to achieve loose coupling:
Message makers and consumers interact with messaging transfers (such as message agents) in point-to-point or publish / booking model. The technical heads provided are often independent of business load.
JMS is very suitable for:
Integrate system / components involved in business events. Integrated slow responders. Integrate existing systems.
The goal of the web service is business services instead of technology connectivity. They are mainly achieved by pine technology coupling but at the interface definition level.
In a web service, coupling is based on interface definitions and protocol bindings.
The contract uses WSDL to release, WSDL defines the interface, and the interface defines the available operations. A variety of protocols used to access Web services. This protocol is called an inbound binding, which defines how to get a confused file. The way to access the implementation is also a variety of ways. This protocol is called an outbound binding, which defines a buffet file that implements a public contract. Examples include JavaBeans, EJB, and JCA.
Coupling in Web services provides flexibility, there are two bindings: static and dynamic.
Static bindings mean tight coupling: requesters are implemented using the service acquisition when designing; there is no need to use private or shared registration centers. Dynamic binding means loose coupling: the requester discovers the implementation of the service called to be called at runtime; it may even determine the interface that should be called at runtime. In reality, most web services use SOAP as an inbound protocol. SOAP is loose coupling agreement until the service level is supported. The service level will handle security, reliability, and availability.
Soap is still the default agreement because SOAP is ubiquitous, firewall friendly and other advantages. In addition, SOAP is a place currently developing a Web service security specification; so in practice, the definition standard security method means using SOAP.
Now, some other auxiliary business functions (such as billing and auditing) are available in Web services.
The portability and interoperability web services are not imposed between the caller with the programming language or operating system restrictions. In the near future, it is very likely to handle some interoperability issues of SOAP, such as the difference between Apache implementation and other implementations. After resolving it, all platforms that support Web services will be interoperable (including .NET and J2EE platforms). But even if it is then, the web service client or server implements code that cannot be transplanted between suppliers. The implementation code written for .NET must not run in J2EE.
JMS and JCA only deal with Java world. With JCA, portable portability can be implemented on the Java client code, and interoperability is limited to specific goals. In order to interoperate at the technical level, JMS requires a Java environment at both ends, but the message load is independent, and the SOAP load can be carried on the JMS by using the JAXM web service.
Transaction support JCA does not always support EIS's end-to-end transaction support. As mentioned earlier, the connector provider implements a container that propagates the transaction context to the target system. This is done through the transaction management system contract, in the contract, the container is used as a transaction manager that controls the EIS as the resource manager. This is based on the XA standard (see Resources for more information).
Web services do not currently support transactions. The Standards Committee is studying the method of providing transaction support in a loosely coupled model with WS-Coordination and WS-Transaction standards. In the future, the loose coupling model using the compensation will appear and a tight coupling model similar to the XA transaction model will appear.
In the message delivery model, the message is passed to the queue, and the client cannot control its propagation. So JMS only supports the team's transaction, does not support the transaction of the target application.
Reliability Currently, the only guaranteed transmission is passed through JMS (although there is no guarantee for message delay). For future needs, IBM, Microsoft, BEA and Tibco have been jointly proposed to exchange security, reliable messages for security, reliable messages in the Web service environment. You can get these criteria at the Web Service Organization Site (see Resources). The reliability of the JCA connection is always specific to the connector, and JCA itself does not mean reliability.
Safety security is the lowest level of standardization. In JMS, the specification clearly defines security by the JMS provider (this implementation is compatible with other J2EE security). Fortunately, IBM also adheres to this standard. In JCA, security support depends on the function of the connector container and the implementation of the target enterprise information system.
HTTPS supports providing some web service security on the transport layer. However, after the Web server decodes and authenticates, it is vulnerable, only some web services that use SOAP security extensions, soap-sec (see Reference) Data for more information on SOAP-SEC). Standardization work on WS-Security standard is underway, WS-Security will implement fully interoperable end-to-end security model in the future. Conclude
As you can see, you need to implement one of the integrated Web services, JMS, and JCA implementations based on multiple standards. The designer can choose the correct implementation for their special conditions by mapping the requirements of certain solutions and the requirements for these requirements.
The following table summarizes the content we have discussed and the standards are available:
Web Services JMSJCA Note Interface Coupled (Abstract Service Definition) is to support dynamic interface discovery and request constructing whether or not the load is not related to "Yes" means that tight coupling technology coupling (protocol stack) is in WSIF, the client is not implemented with an agreement The client library binding is "Yes" means that tight coupling portability is a variety of languages that only Java technology is not only Java technology reliability SOAP HTTP-R binding is a specific transaction support future WS-Coordination and WS-Transaction. The compensation and XA model scope is limited only in the team in the team. The XA model security is limited to SOAPSOAP-SEC (substituted by WS-Security) is not a standard, so the integrated synchronization method specific to the supplier EIS and J2EE is a lot of use. It is a future event driver for an asynchronous way to be a document interface is a future event.
Reference
Get JMS specification in java.sun.com. A complete description of the JCA standard can be found in the Java 2 Connector Architecture (JAVA 2 Connector Architecture, JCA). PAUL FREMANTLE Written "Applying The Web Services Invocation Framework" (June 2002) is an excellent entry reading of WSIF. The WSFL specification (PDF format) describes the web service process language. At the Web Service organization Web site, you can understand the standard mechanisms that exchange security and reliable messages in the web service environment. Review the business process of Web services execution language V1.0 (Business Process Execution Language for Web Services, BPEL4WS) specification. Learn more about Apache Axis. By reviewing all public standards and specifications to learn about the information about the Web Service Protocol Series. SOAP Security Extensions: Digital Signature is well described in the current SOAP security extension (although the extension has been replaced).
About author
