SOA Standards----SCA Architecture ideas

SOA Standards----SCA Architecture IdeasSOA has two sets of standards in the Java World: one is Sun's JBI (not recognized by BEA and IBM) and the other is the SCA and SDO standards introduced by companies such as IBM and BEA. JBI's focus on Java components only handles the integration of Java components. SCA implements the separation of business components and transport protocols, and can handle the integration of various platform components. SDO can freely read data from a variety of different data sources.   In addition, BPEL is essentially a language for integrating Web service services and can also be counted as part of an SOA. In this article, we introduce SCA's architectural ideas in detail. I. Knowledge of SCAThe SCA (service Component Architecture) Chinese translation is a new concept of software architecture, which is a "services component architecture". One of the most important concepts in SCA is service----services, which are content-independent from specific technologies. Therefore, SCA is not called a Java component schema or a Web Service component schema.   The so-called specific technology, mainly has two meanings: one is the programming language, but the transmission protocol. The existing components are tightly coupled with the transport protocol. For example, the EJB component uses the RMI transport protocol, and the Web service component uses the SOAP transport protocol.   SCA components are free to bind various transport protocols.   SCA is a further sublimation of the current component programming, with the goal of allowing the service component to freely bind various transport protocols and integrate with other builds and services.   The biggest difference between SCA and traditional business components is that SCA implements two functions: one is the separation of component and transport protocol, the other is the separation of interface and implementation language.   The nature of SCA is a software architecture idea, and SCA architecture is an SOA architecture that is independent of the programming language.   The goal of SCA is to create a running environment that integrates service components. I need SCA for anything. Answer: the need for integration. Looking at the integration of systems that do not use SOA technology, we need to contract and expose interfaces to each other. The integrated client calling code needs to be written.   The caller and callee need to be "TSE" to be well integrated, which in turn brings high costs and complexity. The benefit of using SCA is that the components are in a loosely coupled state and do not need to include the interface code of the opposing component in their own code. ii. understanding of SCA containersSCA is an idea, and the concrete implementation of SCA is the SCA Standard and SCA's container environment. The SOA container is also divided into JBI containers, SCA containers, and so on. The SCA container is also a generic term for the SOA container, which is usually called the SCA container, and directly general term the SOA container.   In order to differentiate itself from other SOA containers, this is called an SCA container.   SCA containers enable the integration of complex service components within a container, and developers need to develop and integrate services in accordance with SCA standards, and eventually deploy them into SCA containers. The implementation of the SCA container is complex, and the composition and architecture of its container is also a trade secret.   Developers only need a relationship to follow the SCA standards to develop and integrate service components.   In order to better implement SCA architecture, it is very important for developers to understand the connotation and denotation of SCA Service component concepts. To get a clearer understanding of SCA's concepts and principles, here is a simple example of SCA to gain a perceptual understanding of SCA. iii. Examples of Hello World components implemented by SCAComplete SCA Components The Hello World instance contains two parts: 1. The service-side code of the SCA component includes three parts: the service interface, a Java interface----Helloservice.java. Service implementation, the implementation class of the HelloService interface----Helloserviceimpl.java.   SCA's service component configuration file: Hello.composite. Helloservice.java/**
* Service Interface
*
* @author leizhimin 2009-6-2 15:31:49
*/
Public interface HelloService {
String Gethello (string username);
} Helloserviceimpl.java Package Hello;

/**
* Service Implementation
*
* @author leizhimin 2009-6-2 15:32:36
*/
public class Helloserviceimpl implements HelloService {
public string Gethello (string username) {
Return "Hello" + Username + "! This is a SCA program! ";
}
} Hello.composite <!--SCA Service component configuration file--
< composite xmlns = "http://www.osoa.org/xmlns/sca/1.0" name = "Hello" >
< component name = "Helloservicecomponent" >
< Implementation.java class = "Hello." Helloserviceimpl "/>
< property name = "username" type = "Xsd:string", default = "World"/>
</component >
</Composite > 2. Client code for SCA componentsPackage Hello;

/**
* SCA client-side invocation
*
* @author leizhimin 2009-6-2 15:41:41
*/
public class Helloscaclient {
public static void Main (string[] args) {
Scadomain Scadomain = scadomain.newinstance ("Hello.composite");
HelloService HelloService =
Scadomain.getservice (HelloService class, "helloservicecomponent");
String msg = Helloservice.gethello ("vcom");
SYSTEM.OUT.PRINTLN (msg);
Scadomain.close ();
}
From the client's calling code, the client needs to know what services the service-side component provides and what pure Java interfaces are implemented. The implementation details behind the interface are not required. As you can see from the development process above, there is no need to know the technical details of developing SCA components, both client and server.   When the client calls other components, it can be called only through a simple scadomain instance, and the responsible invocation and implementation are given to the SCA runtime environment. As you can see from the build example above, the service component is the basic unit of the SCA Architecture, and SCA is integrated with the service component as the base unit. The concepts of the various service components are described below. Iv. Service Components1, the concept of service components accurately say there is no precise concept, it is closer to a tangible object, only from his shape, composition, structure, function, state, attributes and other aspects to describe it. The service component is the most basic functional unit of SCA, it mainly includes the interface, implementation, reference, attribute and so on. Service components can be described from the side. A), is an instance of an implementation that is generated within a module (COMPOSIT) through configuration. b), multiple components can be implemented in the same implementation (think: A Java object can implement multiple interfaces at the same time). c), provision of services and consumer services (components can invoke services of other components). d), the property value of the object is implemented by configuration (the configuration node is properties). e), the component sets the service reference by wire.   A connection can be connected to a service of another component, or it can be connected to a reference to a module (which is described in detail later in the module's concept).   2. The components of a serviced component consist of four parts: a service, a component implementation, a reference, a property creation. The following diagram shows the structure of the serviced component:
As shown above, each part of the service consists of a: a), a service, which is used for other components to invoke. is an interface. If it is Java-based SCA, it is the interface of Java, it can also be the Prottype interface of WSDL, there are only these two forms. b), component implementation (implementation), the implementation of the service created, for Java, is the interface implementation class. c), reference (Reference), a component may need to call other components and need to create a reference to the Igeqita component. For Java, it is the Java interface for other components.   d), property, an attribute parameter injection to the component implementation. For a serviced component, the services and implementations are required, and references and attributes are not required. For example, for the example above Hello World, the structure of the component is as follows:
Five, Service moduleSCA is the integration of SCA components through modules (Composite). The SCA module is actually a more integrated set of SCA components (as parts), and the structure of SCA modules and SCA components is consistent from the overall perspective.   From the part angle that makes up the component, the SCA module is reassembled as a new component (module) as a component. In fact, the truth is very simple, the following is the basic principle of SCA Module diagram:
As you can see above, the module is also a component in its entirety. Modules are assembled through the SCA configuration file configuration and do not require the hard coding of the program. Elevation (Promote): The interface, attribute, or reference of a component is assembled into the corresponding interface, property, or reference of a module. Wire: Is the call relationship between components within the module. For example, the implementation of component A calls component B, so there is a connection between component AB. When calls are needed between components, because of the diversification of current components (such as EJB, WS, JMS) transport protocols, it is necessary to bind different protocols to each other when called. Here, as far as possible, avoid the notion of a confusing and worthless binding. VI. Service SubsystemIn a large project, there may be a lot of service modules, multiple service modules if you need to call each other, then you can be a number of service modules through WS or JMS and other technologies to bind together to form a service subsystem. Understanding the concept of the module, it is not difficult to understand the service subsystem. vii. Similarities and differences of SCA and JBI1, the same point purpose is the same: all for integration. Roughly the same direction: all in order to decouple the service from the transport protocol. 2, the different point SCA takes the interface as the entry point, from the component interface layer to decouple the transmission protocol and the interface realization, is from the programming angle, a new programming model. JBI is the request message and the corresponding message as a pointcut, in the integration of the message and transport protocol decoupling, the formation of a transport protocol-independent standard message, so as to form a completely different from the existing Application Server integration container, from the container point of view, a new container model. Personal Opinion: Jbi is the sun's own standard, not recognized by companies such as IBM and Oracle. At present, there is no support from commercial container developers, the outlook is not good, the current information and documentation is quite small. Personal recommendations for JBI applications should be used with caution, and if SOA is used, use more mature SCA scenarios whenever possible.