Poulin, I didn´t get your criticism on the article/methodology. Can you develop it?
[]s On Tue, Mar 24, 2009 at 7:13 PM, Michael Poulin <[email protected]> wrote: > If Architects should know about SCA, I think, they should not know about "As > the industry is moving from using an application-centric architecture to a > Service Oriented Architecture (SOA), the focus for building functionality is > moving to Service Oriented Business Applications (SOBA)"; SOBA even after > recent update is the 'last Winter thing' with its Interface=Service, > Service=Web Service and Business=Process. How a methodology may be right if > it is based on three wrong statements? > > - Michael > > > > > ________________________________ > From: Gervas Douglas <[email protected]> > To: [email protected] > Sent: Tuesday, March 24, 2009 9:02:08 AM > Subject: [service-orientated-architecture] den Haan explains SCA > > <<What every architect should now know about the Service Component > Architecture (SCA) > > 11 March 09 - 11:52 Johan den Haan > The definition of ‘application' is rapidly changing. As the industry is > moving from using an application-centric architecture to a Service Oriented > Architecture (SOA), the focus for building functionality is moving to > Service Oriented Business Applications (SOBA). This means that applications > are a set of services and components working together in fulfilling a > certain business need. The technology, specifications, and standards for > specifying these components and services may vary, and most often religious > discussions are going on about the usefulness of each of them. > > As regular readers may guess, my take would be to create these components > and services in a model driven way using an approach to Model Driven SOA. > However, even in that case you'll need some kind of programming model that > defines interfaces, implementations, and references. When building an > application or solution based on services, these services can be both > created specifically for the application and reused from existing systems > and applications. Hence, we need a programming model that specifies how to > create and implement services, how to reuse services, and how to assemble or > compose services into solutions. > > That's exactly what the Service Component Architecture (SCA) is. > > Structure of this article: > > Introducing the Service Component Architecture (SCA): the who and why behind > SCA. > Service Component Architecture specifications: explaining the four main > elements of the SCA. > Service Component Architecture concepts: explaining the concepts (e.g. > composite, component, service, wire, binding, reference, etc.) of the SCA in > detail. > Deployment and the Service Component Architecture: contributions, clouds, > and nodes. > Implementations of the Service Component Architecture: an overview of > existing SCA implementations (open source and commercial). > > Introducing the Service Component Architecture (SCA) > > The SCA models the "A" in SOA. It provides a model for service construction, > service assembly, and deployment. The SCA supports components defined in > multiple languages, deployed in multiple container technologies, and with > multiple service access methods. > > The SCA consists of a set of specifications that define a model for building > Service-Oriented Business Applications (SOBA). These specifications are > based on the following design principles: > > OSOA" class="pivot-image"> > > Independent of programming language or underlying implementation. > Independent of host container technology. > Loose coupling between components. > Metadata vendor-independence. > Security, transaction and reliability modeled as policies. > Recursive composition. > > The first draft of SCA was published in November 2005 by the Open SOA > Collaboration (OSOA). OSOA is a consortium of vendors and companies interest > in supporting or building a SOA. Among them are IBM, Oracle, SAP, Sun, and > Tibco. In March 2007 the 1.0 final set of specifications was released. In > July 2007 the specifications were adopted by OASIS and they are developed > further in the OASIS Open Composite Services Architecture (Open CSA) member > section. > > Service Component Architecture specifications > > The set of specification can be split into four main elements: the assembly > model specification, component implementation specifications, binding > specifications, and the policy framework specification. I will shortly > explain each of them in this section. In the next section I'm going to > explain the concepts (e.g. what is a composite, what is a wire, etc.) of the > SCA in more detail. > > Assembly model specification, this model defines how to specify the > structure of a composite application. It defines what services are assembled > into a SOBA and with which components these services are implemented. Each > component can be a composite itself and be implemented by combining the > services of one of more other components (i.e. recursive composition). So, > in short, the assembly model specifies the components, the interfaces > (services) for each component, and the references between components, in a > unified, language independent-way. I'll explain these concepts in detail in > the next section. The assembly model is defined with XML files. > > SCA Assembly Model V1.00 (PDF) > SCA Core XML Schema V1.0 (XSD file) > > Component implementation specifications, these specifications define how a > component is actually written in a particular programming language. > Components are the main building blocks for an application build using SCA. > A component is a running instance of an implementation that has been > appropriately configured. The implementation provides the actual function of > the component and can be defined with a Java class, BPEL process, Spring > bean, and C++ or C code. Several containers implementing the SCA standard > (meaning that they can run SCA components) support additional implementation > types like .Net, OSGI bundles, etc. In theory a component can be implemented > with any technology, as long as it relies on a common set of abstractions, > e.g. services, references, properties, and bindings. I'll explain these > abstractions in detail in the next section. > > The following component implementation technologies are currently described: > > SCA Java Component Implementation V1.00 (PDF), XSD file > SCA Spring Component Implementation V1.00 (PDF) > SCA BPEL Client and Implementation V1.00 (PDF) > SCA C++ Client and Implementation V1.00 (PDF), XSD file > SCA COBOL Client and Implementation V1.00 (PDF) > SCA C Client and Implementation V1.00 (PDF) > > Binding specifications, these specifications define how the services > published by a component can be accessed. Binding types can be configured > for both external systems and internal wires between components. The current > binding types described by OSOA are bindings using SOAP (web services > binding), JMS, EJB, and JCA. Several containers implementing the SCA > standard support additional binding types like RMI, Atom, JSON, etc. An SCA > runtime should at least implement the SCA service and web service binding > types. The SCA service binding type should only be used for communication > between composites and components within an SCA domain. The way in which > this binding type is implemented is not defined by the SCA specification and > it can be implemented in different ways by different SCA runtimes. It is not > intended to be interoperable. For interoperability the standardized binding > types like web services have to be used. > > Officially described binding types: > > SCA Web Services Binding V1.00 (PDF), XSD file > SCA JMS Binding V1.00 (PDF), XSD file > SCA EJB Session Bean Binding V1.00 (PDF), XSD file > SCA JCA Binding V1.00 (PDF) > > Policy framework specification, describing how to add non-functional > requirements to services. Two kinds of policies exist: interaction and > implementation policies. Interaction policies affect the contract between a > service requestor and a service provider. Examples of such policies are > message protection, authentication, and reliable messaging. Implementation > policies affect the contract between a component and its container. Examples > of such policies are authorization and transaction strategies. > > SCA Policy Framework V1.00 (PDF), XSD file > SCA Transaction Policy V1.00 > > Service Component Architecture concepts > > In the previous section we've seen the different SCA specifications and what > they describe. Let's now look in more detail at the concepts of the SCA. > > As stated before the main building block of a Service-Oriented Business > Application is the component. Figure 1 exhibits the elements of a component. > A component consists of a configured piece of implementation providing some > business function. An implementation can be specified in any technology, > including other SCA composites. The business function of a component is > published as a service. The implementation can have dependencies on the > services of other components, we call these dependencies references. > Implementations can have properties which are set by the component (i.e. > they are set in the XML configuration of a component). > > SCA Component diagram" class="pivot-image"> > > Figure 1 - SCA Component diagram > > Components can be combined into assemblies, thereby forming a business > solution. The SCA calls these assemblies composites. As shown in figure 2 a > composite consists of multiple components connected by wires. Wires connect > a reference and a service and specify a binding type for this connection. > Services of components can be promoted, i.e. they can be defined as a > service of the composite. The same holds for references. So, in principle a > composite is a component implemented with other components and wires. As > stated before, components can in their turn be implemented with composites > thereby providing a way for a hierarchical construction of a business > solution, where high-level services (often indicated as composite services) > are implemented internally by sets of lower-level services. > > SCA Composite diagram" class="pivot-image"> > > Figure 2 - SCA Composite diagram > > The service (or interface if you like) of a component can be specified with > a Java interface or a WSDL PortType. Such a service description specifies > what operations can called on the composite, including their parameters and > return types. For each service the method of access can be defined. As seen > before, the SCA calls this a binding type. > > Figure 3 - Example XML structure defining a composite > > Figure 3 exhibits an example XML structure defining an SCA composite. It's > not completely filled in, but it gives a rough idea what the configuration > looks like. The implementation tag of a component can be configured based on > the chosen implementation technology, e.g. Java, BPEL, etc. In case of Java > the implementation tag defines the Java class implementing the component. > > Deployment and the Service Component Architecture > > SCA composites are deployed within an SCA domain. An SCA Domain (as shown in > Figure 4) represents a set of services providing an area of business > functionality that is controlled by a single organization. A single SCA > domain defines the boundary of visibility for all SCA mechanisms. For > example, SCA service bindings (recall the earlier explained SCA binding > types) do only work within a single SCA domain. Connections to services > outside the domain must use the standardized binding types like webservice > technology. The SCA policy definitions do also only work within the context > of a single domain. In general, external clients of a service that is > developed and deployed using SCA should not be able to tell that SCA was > used to implement the service, it is an implementation detail. > > SCA Domain diagram" class="pivot-image"> > > Figure 4 - SCA Domain diagram > > An SCA domain is usually configured using XML files. However, an SCA runtime > may also allow the dynamic modification of the configuration at runtime. > > An SCA domain may require a large number of different artifacts in order to > work. In general, these artifacts consists of the XML configuration of the > composites, components, wires, services, and references. We of course also > need the implementations of the components specified in all kinds of > technologies (e.g. Java, C++, BPEL, etc.). To bundle these artifacts the SCA > defines an interoperable packaging format for contributions (ZIP). SCA > runtimes may also support other packaging formats like JAR, EAR, WAR, OSGi > bundles, etc. Each contribution at least complies to the following > characteristics: > > It must be possible to present the artifacts of the packaging to SCA as a > hierarchy of resources based off of a single root. > A directory resource should exist at the root of the hierarchy named > META-INF. > A document should exist directly under the META-INF directory named > ‘sca-contribution.xml' which lists the SCA Composites within the > contribution that are runnable. > > A goal of the SCA approach to deployment is that the contents of a > contribution should not need to be modified in order to install and use the > contents of the contribution in a domain. > > An SCA domain can be distributed over a series of interconnected runtime > nodes, i.e. it is possible to define a distributed SCA domain. This enables > the creation of a cloud consisting of different nodes each running a > contribution within the same SCA domain. Nodes can run on separate physical > systems. Composites running on nodes can dynamically connect to other > composites based on the composite name instead of its location (no matter in > which node the other composite lives), because they all run in the same > domain. This also allows for dynamic scaling, load balancing, etc. Figure 5 > shows an example distributed SCA domain, running on three different nodes. > In reality you don't need different nodes (and even different components) > for this example, but it makes the idea clear. > > SCA domain running on multiple nodes" class="pivot-image"> > > Figure 5 - A distributed SCA domain running on multiple nodes > > Implementations of the Service Component Architecture > > The SCA is broadly supported with both commercial and open source > implementations. To give you an idea I'll list a few them below. > > Open source implementations: > > Apache Tuscany (official reference implementation). The current version is > 1.4, released in January 2009. They are also working on a 2.0 version which > they aim to run in an OSGi enabled environment. > The Newton Project. > > Commercial implementations: > > ActiveMatrix Service Grid from TIBCO. > Oracle Tuxedo. > IBM WebSphere Application Server Feature Pack for SCA. > > Do you have experience with one of these products? Do you use SCA in > practice? > > ------------ > Figure 1, 2, and 4 are taken from the SCA Assembly Model specification. > Figure 5 is taken from the Tuscany documentation.>> > > You can find this at: > > http://www.theenterprisearchitect.eu/archive/2009/03/11/what-every-architect-should-now-know-about-the-service-component-architecture-sca > > Gervas > > -- Marcelo Augusto Costa ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
