I see... Tks! On Sun, Apr 5, 2009 at 11:56 AM, Michael Poulin <[email protected]> wrote:
> Augusto, > > SOBA is interpreted as 'SOB Application' as well as 'SOB Architecture' in > our days. My comment relates to both. Why? Here is a short story: in Udi's > BLOG I asked - > MP: "what's the place/role of SOBA in SOMA?" > Tilak Mitra [co-author of 'Executing- SOA-Practical- Service-Oriented > -Architect', the book that discussed the recent update of IBM SOMA]: "SOMA > provides prescriptive techniques and guidance on how to extend the SOMA > method to develop SOBA's" ( > http://www.mail-archive.com/[email protected]/msg08468.html > ) > > If we still lock ourselves in IT, we think that a collection of technical > services can constitute a business application. I disagree. I insist on that > business application has to be constructed based on business services some > of which may be implemented using technical services. A service becomes > business service not because Business uses it but because it implements > business function, feature, service, or process. If a SW component just > carries business data, it is a driver/object, not a service because it > implements technical task, not a business task. > > If SOBA is constructed by SOMA where 'Interface=Service, Service=Web > Service and Business=Process', I do not think it is a service-oriented > business application. It is, probably, an aggregation of integrated > applications utilising Web Services as the integration technology; whether > it implements any business functionality or not is an open question. Use of > Web Services does not automatically constitute service, and, especially, > service-oriented business service. > > - Michael Poulin > > ------------------------------ > *From:* Marcelo <[email protected]> > *To:* [email protected] > *Sent:* Friday, April 3, 2009 1:49:34 PM > *Subject:* Re: [service-orientated-architecture] den Haan explains SCA > > 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 > > > > > > -- Marcelo Augusto Costa
