Overview

SOA is about providing software capabilities through interfaces called services and supporting the business concept known as service orientation, where applications are built as sets of services with service users unaware of how or where services are implemented. Beyond the interfaces—which are a key part, but not the only part of a good SOA—are software components and component models. Component models are useful for building new SOA services from the ground up, but they're also useful for creating SOA services from legacy IT assets. You can use component models to provide abstraction of legacy services and to re-engineer existing legacy assets, especially when the component model supports language neutrality.

There are many aspects to the concept of a software component. This article focuses on software components as they're used within the context of an SOA-based business service solution. In this context, you can use various software component technologies to:

• Implement business services.
• Adapt services for integration between disparate run times, languages, or interfaces.
• Provide a business-level abstraction for the composition of preexisting business services.

The software component concept can be decomposed into what this article calls coarse-grained components and fine-grained components. Unfortunately, it's not possible to define these two concepts precisely. There's a wide-ranging opinion in the industry on how to precisely delineate component granularity. For example, the OASIS SOA Reference Model (see Resources for a link) specifically rejects the notion that interface chattiness is a consideration. By contrast, the Wikipedia definitions (see Resources) primarily center on the frequency and amount of data exchanged between components. Further, the industry has adopted the concept of coupling, which is defined as the fragility exhibited in the relationship between two software components. The terms loose coupling (a small amount of fragility) and tight coupling (a large amount of fragility) are often mistakenly used as synonyms for coarse-grained and fine-grained components.

This article asserts that coupling is only one aspect of granularity, as discussed in the Component interface section, but does support the current industry thinking that, in general, loosely coupled components are coarse grained, while tightly coupled components are more likely to be fine grained. It's worth noting that while some component models focus on one form of granularity, others attempt to strike a balance between the two extremes. (See the Inventory of component technologies section for a categorization of component models based on the attributes described in this article.)

In reality, component granularity is influenced by a set of factors, as shown in Figure 1.

Each of the attributes that plug into the continuum exerts an influence on component granularity to varying degrees. For example, the diagram in Figure 1 specifically asserts that the level of abstraction and the form of data representation have a large influence on the granularity of the component being evaluated. This article contains sections that discusses each of the attributes in more detail.

Do you plan to build coarse-grained or fine-grained components? Choosing the right component model for the job isn't easy. Many choices exist today in the industry, each with overlapping capabilities, each competing for mind share. Selection of a component model requires an understanding of the dimensions of the business problem in the context of SOA best practices and current IT technologies. This article gives you a set of guidelines to use in categorizing software component technology in the context of SOA, which enables the most effective use of those technologies within IBM's middleware products. It also positions the various component technologies prevalent in the industry today. Here, you can evaluate and get descriptions of many of the attributes from Figure 1, and get examples that help describe the impact these factors have on overall granularity.

This article covers the following main topics:

• Functional characteristics: Describes the granularity dimensions to be considered when constructing components, such as interface and implementation.
• Nonfunctional characteristics: Discusses the aspects of component models that affect how components are packaged, deployed, and scaled in large enterprise applications.
• SCA and other component models: Describes how these component models map to the component granularity dimensions described in this article.

Back to top

Functional characteristics of components

When assessing component granularity, it's helpful to break down the functional aspects of a component into a dichotomy that permits a deeper analysis. However, there's no one aspect that can be used to definitively state the granularity of a component. Rather, it's always a combination of aspects that work together to produce a statement about granularity. As you examine each aspect here, you get general guidance as to the tendencies toward each end of the granularity continuum.

The functional aspects of a component encompass a concrete realization of the shape, structure, and organization of a component in some programming language, metadata description, or other machine-readable format. As such, component interfaces and implementations come into focus when distinguishing granularity.

Note that the choice of implementation language is generally not important when trying to assess the granularity in a component technology.

Component interface

A component interface is generally described as a formalized abstraction that an entity provides as the outward facing view of itself. To generally differentiate granularity, this section examines the aspects of:

• Interface coupling
• Data (type systems and message formats)
• Version resiliency
• Transport independence
• Expected interaction patterns
• Conversations
• Ability to mediate
• Dynamicity

Let's look at these in more detail:

Interface coupling: The degree of coupling that exists between a service consumer and a service provider is determined by how independently they can evolve. Coarse-grained components exhibit loose coupling, whereas fine-grained components are often tightly coupled. For example, if recompiling both the consumer and the provider resolve some problem in the interaction, then the two components were tightly coupled. There are several aspects of interface coupling that contribute to the degree of independence. These include data, versioning, transport independence, interaction pattern, conversation, and mediation.

Data: Exchanging data via documents promotes loose coupling between the service consumer and provider, because a document is a canonical, programming language-independent form of the data. By contrast, component interfaces that expose programming language-specific forms of data promote tight coupling, because this usually forces the use of the same programming language on each side of the interface. Using data structures that don't easily map to a document tends to produce tight coupling. Object-oriented graphs are an example of data structures that don't easily map to documents. Hierarchical data structures map very well into documents. Further, the quantity of data exchanged between service consumers and providers is also an indication of component granularity. Coarse-grained components tend to exchange larger messages than fine-grained components. Fine-grained components tend to exchange smaller messages, because there are usually more interactions.

Versioning: The ability of a service provider to support clients that may not be aware of a specific version of an interface promotes loose coupling. That is, consumers and providers that can evolve independently are loosely coupled and, therefore, are usually coarse grained.

Transport independence: A service with an implementation that's not dependent on a specific transport or protocol mechanism promotes loose coupling. The ability to change or to add additional transport and protocol endpoints to a service enables the service to be used by a wider range of consumers.

Interaction pattern: Interfaces with a document style interface design (see the paragraph on data, above) in combination with a small number of interactions between a consumer and provider exhibit loose coupling, because that service can more easily be replaced with a different service without affecting consumers. In fact, a document-centered data model usually implies fewer interactions. This combination of attributes strongly suggests a coarse-grained component. A fine-grained component would likely have an interface with less data per operation (not a document) and thus would be more "chatty" (including the use of get and set methods on the interface) requiring more out-of-band knowledge to use the interface. Fine-grained components also tend to interact on the same thread of execution, which reduces the overhead of a chatty interaction pattern. Coarse-grained component models usually include support for asynchronous multi-threaded interactions, which loosens the temporal coupling of components. Also, note that the nonfunctional aspects of latency and distributability are related to the component's interaction patterns.

Conversations: A conversation is a special form of interaction pattern where the parties involved have awareness of previously exchanged messages (that is, the parties hold state information). This awareness usually takes the form of a key or identifier that can be used to correlate messages. Message correlation that's performed by a hosting run time is called implicit correlation from the perspective of the consumer or provider. Implicit correlation can lead to tight coupling, because it might limit transport independence due to the requirement for a transport and protocol that can achieve implicit correlation. Explicit correlation occurs when the component interface includes business data that can be used to correlate messages. Therefore, component interfaces that exploit implicit correlation are structured differently from nonconversational interfaces. Explicitly correlated interfaces contain extra parameters (the correlators) in operation signatures or include metadata to indicate where the correlators can be found in the business data, for example, an XPath expression pointing into one of the operation parameters. Explicit correlation can lead to tight coupling if the correlator is infrastructural data that should not be intermixed with business data. Finally, a conversational interaction does represent a temporal coupling of components, but it has application in both fine- and coarse-grained components, thus it's not a strong indicator of granularity.

Mediation: The ability to mediate the interface between two components implies coarse-grained components with a loosely coupled relationship. Mediation can occur on the client side, the service side, or on the wire in between. The various mediation points allow loosely coupled services to be proxied or "gatewayed" by a service bus. This capability is enabled by coarse-grained data and interaction patterns. Coarse-grained services can be connected to a service bus and, thus, can be mediated, allowing logic to be interposed between the requester and the provider. This isn't something expected in a fine-grained component model. The desire to mediate the interaction of two components is often more easily accomplished in fine-grained components by directly modifying the component implementations or configurations. This also reduces overhead at execution time. Therefore, the idea of using a mediation pattern on existing fine-grained components is rarely useful. The ability to interpose quality-of-service semantics can be viewed as a form of mediation. That aspect of a component model is covered in the Nonfunctional characteristics of components section.

Dynamicity: The amount of effort required to introduce a change to the composition of an existing IT system is a function of coupling between the components. Loosely coupled services are less resistant to change, enabling a more agile IT environment. Tightly coupled services tend to cause a ripple effect in the system, as one change cascades to require another change. There may also be operational semantics to consider when introducing a change. Services that need to be stopped and restarted because they can't support versioning or compatibility with older consumers are also indicative of tightly coupled services.

Component implementation

A component implementation is generally described as the realization of an algorithm or other technical description of a function. This section examines the aspects of substitutability, life cycle, state, and abstraction to generally differentiate coarse- and fine-grained components.

Language neutrality: A component implementation that can be replaced with a different one, possibly in another language, without affecting its consumers or the encapsulating business processes exhibits a high degree of independence and therefore falls into the category of a coarse-grained component. A component implementation can also be replaced by a mediation or gateway pattern such that independence can also be achieved by injecting some additional value into the interaction and then delegating to the real service implementation. Implementation flexibility is strongly indicative of a coarse-grained component. Within the context of a component implementation, there are some aspects that should also be considered.

Container independence: In a managed component environment, components are hosted within a container. Some containers impose themselves into the business logic of a component in the form of framework methods. Mixing the framework with the business logic restricts the set of containers in which the component can be hosted. Enterprise JavaBeans (EJB) 2.0 or later is an example of such a component model. The introduction of code annotations alleviates this dependence to some extent, but not completely. The use of annotations creates the same kinds of container dependence issues, but it's possible for different containers to support a common set of annotations that could loosen the coupling with a container if the business logic constrains itself to the use of the common annotations. This isn't possible when frameworks are mixed into business logic. Fine-grained components are generally not portable across different containers, because they tend to make extensive use of a container framework, while coarse-grained components generally are more portable.

Runtime life cycle: The consumer's awareness of (and subsequent dependence on) the runtime state or readiness of a service provider is indicative of tightly coupled behavior. The Interaction pattern explanation (above) describes how interaction patterns contribute to component granularity. Component implementations acting as a service provider can contribute to the intercomponent coupling by letting their consumers observe the runtime life cycle of the provider. Often this is done in combination with a chatty interface or even a conversational interface design. Component implementations that expose life cycle state to their consumers are generally considered to be fine-grained components.

Abstraction: A coarse-grained component should have a direct mapping to an abstraction that would be recognized in the business model and be understood by business people. Coarse-grained components are usually implemented through composition of finer-grained components as a means for obtaining abstraction. Often, a user of the IT system (such as a bank teller) is aware of the coarse-grained services in the business model. Coarse-grained services correspond more closely to the notion of an SOA service. Fine-grained components are more numerous and are used to organize the implementation of logic in a system, often implementing a detailed technical algorithm.

Persistence: Business data is stored persistently in many different ways. Business components need to read and manipulate that data to perform their business functions. Fine-grained software components often use APIs that are specific to a particular persistence mechanism, for example, JDBC for access relational data from a Java™ component implementation. Coarse-grained components tend to use other component services, such as data services, to obtain business data. A data service encapsulates the persistence mechanism, which allows the consuming component to be independent of the persistence mechanisms used by the data service. Despite the distinctions illustrated here, the use of a persistence mechanism doesn't strongly influence the granularity of a software component. Persistence is simply one example of language dependence or possibly even container dependence.

Example using Service Component Architecture (SCA)

To further illustrate the concepts discussed in the preceding sections, let's examine an SCA example. The following example shows the SCA assembly for the BigBank sample. This sample has been used quite extensively throughout the SCA V1.0 specifications. The assembly diagram is annotated to show the main drivers of granularity.

The Appendix contains the Service Component Definition Language (SCDL) for both assemblies and alternatives to the use of SCA composition for the bigbank_account composition. Each alternative contains the same loosely coupled contracts evident in the AccountService and stockquote reference, but implements the Account and AccountData components quite differently.

The coarse-grained SCA component model enables the following attributes of granularity:

• Abstraction: The use of a non-SCA composition to implement a coarse-grained component. The ability to define specific service interface contracts in the coarse-grained AccountService and StockQuoteService components through SCA's service and reference concepts.
• Data: The use of document style interface design to promote loose coupling
• Transport independence: SCA abstracts transport/protocol configuration away from components and into the SCA binding concept. It allows the fine-grained assembly (bigbank_account) to avoid transport/protocol configuration, which can be provided late in the deployment cycle.
• Interaction pattern: Loosely coupled interaction patterns are evident between the Account component and the StockQuoteService component, because neither has any knowledge of the other.
• Mediation: The Account component and StockQuoteService interactions can be mediated easily by the addition of a mediation component in the bigbank composition, because it doesn't disrupt any of the fine-grained assembly in the bigbank_account composition.
• Language neutrality: The components in the assembly can be implemented in any programming language that's capable of expressing the service contracts represented in the assembly. The components in the bigbank_account composite are implemented in the same programming language due to the fine-grained intracomposite interactions.
• Locality: The components in the bigbank composite can be deployed anywhere in the enterprise. The SCA assembly model provides a location-independent addressing scheme that enables this flexibility.
• Quality of service (QoS): The SCA Policy Framework provides the ability to declare abstract QoS requirements that are bound to concrete policy during deployment of the services.

Back to top

Nonfunctional characteristics of components

The nonfunctional aspects of a component are more abstract than the functional aspects. Individually, the nonfunctional aspects listed below have less bearing on granularity than the previously discussed functional aspects. Nonfunctional characteristics, when applied to the problem of defining granularity, are more subjective in nature and, thus, are inadequate as the sole means for quantifying granularity. Therefore, the following nonfunctional aspects of components should be evaluated in combination with other nonfunctional aspects as well as the functional aspects described above.

The nonfunctional aspects of a component include, but are not necessarily limited to, measures of quantity about the component. The list below covers aspects of latency, distributability, scalability, footprint, and qualities of service to the extent that these attributes can be used to distinguish granularity. The relevance of any one of the following nonfunctional characteristics can be altered or even invalidated by technology advances in hardware or software.

Latency: The expected response time of component interactions is important, because it may constrain the choice of component granularity. In general, coarse-grained components exhibit response times that are significantly longer than fine-grained components. This is due to functional characteristics related to interface coupling and other nonfunctional characteristics.

Locality: The ability to physically separate components without affecting the behavior of the IT system is a key attribute of loosely coupled coarse-grained components. Fine-grained components often require collocation to operate correctly or, more likely, to provide the low latency that's necessary to achieve a performance goal. Collocated, fine-grained components also usually exhibit, or at least are designed for, a chatty interaction pattern.

Scalability: The ability to scale both horizontally and vertically is a very important characteristic of a growing IT system. In general, stateless interaction patterns scale better than others. However, due to technology advances in hardware and software (especially in the areas of caching and state replication), it's often possible to achieve highly scalable systems using any interaction pattern and using components of any granularity, which are either tightly or loosely coupled. Scalability seems to have little to do with component granularity.

Footprint: The amount of virtual memory required to execute the component can determine its granularity. Because coarse-grained components are usually composed of many finer-grained components, the execution of a coarse-grained component consumes memory equivalent to the sum of all its composed components. Note: Coarse-grained component models, because they are language independent and enable some of the other characteristics discussed, will likely have a memory expansion factor that's higher than that of a fine-grained model. Because coarse-grained models support things like language independence and local-remote transparency, the in-memory models they use are regularly expected to be more verbose than a fine-grained model that supports and is centered on a specific programming language.

QoS: QoS exploitation (security, reliability, transactions, service level agreement [SLA], and so on) is another crucial element. In general, coarse-grained component implementations are decoupled from QoS-related APIs and rely on their container to act on metadata or deployment descriptors to provide the desired quality of services. This allows coarse-grained components to be more configurable in the context of QoS. Fine-grained components tend to be tied to specific QoS APIs, which puts constraints on the functional aspects of implementation substitutability and transport independence. Many component models support the notion of third-party interception, which enables the introduction of extended qualities of service that were not provided by the original runtime vendor. In general, this kind of interception between fine-grained components can lead to performance problems and is therefore usually done on coarse-grained boundaries. However, the exploitation of these extended QoS capabilities can have the same tight-coupling effect as experienced when a component implementation uses a built QoS API.

Back to top

SCA programming model details

The primary use cases for the SCA programming model revolve around the ability to abstract business function into loosely coupled services that are implemented by coarse-grained components, compositions of fine-grained components, and compositions of coarse-grained components. SCA provides composition on two axes: composition by reference and composition by implementation. SCA components can compose services by orchestrating the invocation pattern of those services through a single invocation programming model that's independent of where and how the services are deployed. SCA can also provide composition by implementation through the use of an assembly of finer-grained components as the implementation of a coarse-grained component. Fine-grained components are found at the leaves of composition by implementation; coarse-grained components are found at the root. The example application in the SCA example section demonstrates both forms of composition.

Table 1 breaks down the main characteristics of the SCA plain old Java object (POJO) programming model into coarse-grained and fine-grained aspects. To meet the needs of a coarse-grained component model, all the items in the fine-grained column should be considered optional parts of the SCA component model. This table is based on the V1.0 specifications produced by the Open Service Oriented Architecture (OSOA) collaboration.

There are many more features and functions (for example, persistence mechanisms, threading semantics, and so on) that are present in other component models but which are not present in SCA V1.0. This is due to the primary focus on coarse-grained assembly.

Back to top

Inventory of component technologies

Table 2 categorizes, in general, the various component technologies in terms of their usage as fine- or coarse-grained component models. This table concentrates on the aspects that have the largest effect on granularity, namely abstraction, data format, transport independence, interaction pattern, and mediation.

Back to top

Summary

Component models provide value when building software systems. This value comes in the form of abstraction and enablement of composition. In providing for good abstraction, component models must encapsulate the details of the various implementation aspects that components might require.

Classifying component granularity and understanding how to leverage component models is not a science. This article has provided some background on the dimensions and attributes of components and the component models in which they live, paying specific attention to the idea of granularity.

Fine-grained components have a set of characteristics that allow them to be used as an organizing pattern throughout the implementation of logic in a system. If your application component requirements include microsecond response time, low latency, the ability to handle pass-by-reference semantics, presuming synchronous processing, and being tightly coupled to the caller's execution context (language, QoS, locality), then your component is fine grained and should be developed using a fine-grained component model.

Coarse-grained components are reserved to a smaller set of abstractions in a business system. Coarse-grained components match more directly to the services in an SOA and map more readily to things that would be recognizable from a business model. If your application component requirements include being independent of the caller's execution context (language neutral, conditioned by independent QoS and locality), being reusable in a variety of contexts, supporting asynchronous processing, or being intolerant of pass-by-reference semantics, then your component is coarse grained. It needs to be designed with coarse-grained principles, including tolerance for millisecond (or more) latency, exchanging large document-oriented data sets, enabling more work with fewer interactions, and removing any dependencies on communication technology.

Share this...

	Digg this story
	Post to del.icio.us
	Slashdot it!

SCA provides a natural model for coarse-grained components. SCA supports a wide variety of component implementation technologies and is capable of connecting between those heterogeneous technologies. Asynchronous and synchronous interaction styles are supported, along with a wide range of communication technologies. Application of infrastructure capabilities through policies applied to components and to the connections between them are also a strength by enabling the use of components in a wide variety of contexts. Mediation of communications is also modeled in SCA.

One of the strengths of SCA is its ability to combine with a wide variety of fine-grained component models that are used to implement coarse-grained service components. SCA brings value to each of them in terms of modeling the structure of solutions in the large, providing agility and flexibility, and removing the need to define complex configuration details within implementation code. It also has the virtue of being able to connect different component models used for different parts of an overall solution.

Back to top

Appendix

Listing 1 is the SCA composite for the bigbank composition. Note that the implementation of the AccountService component is abstract and loosely coupled to the extent that its implementation can easily be provided by any one of a number of fine-grained component models. Listing 1 continues to show concrete examples of various fine-grained component models plugging in as component implementations.

                
<composite name="bigbank" xmlns="http://www.osoa.org/xmlns/sca/1.0">

	<component name="AccountService">
	   <implementation.composite name="bigbank_account"/>
		or
	   <implementation.spring ... />
		or
	   <implementation.ejb3mod ... />
		or
	   <implementation.zero ... />
		or
	   <implementation.pojo ... />
		or
	   <implementation.osgi ... />
		...

	  <reference name="stockquoteService" target="StockQuoteService"/>
	  <property name="currency">EURO</property>
	</component>


	<component name="StockQuoteService">
	   <implementation. ... />
	</component>

</composite>
      

Listing 2 is the SCA composite for the bigbank_account composition.

                
<composite name="bigbank_account" local="true" xmlns="http://www.osoa.org/xmlns/sca/1.0" >

	<service name="Account" promote="Account"/>
	<reference name="stockquote" promote="Account/stockquote" />
	<property name="currency" type="xs:string"/>

	<component name="Account">
	   <implementation.java class="bigbank.account.AccountServiceImpl"/>
	   <reference name="accountdata" target="AccountData"/>
	   <reference name="stockquote"/>
	   <property name="currency" source="$currency"/>
	</component>

	<component name="AccountData">
	   <implementation.java class="bigbank.accountdata.AccountDataServiceImpl"/>
	</component>

</composite>
      

Listing 3 is a plain old Java object (POJO) implementation of the Account component:

                
public class BigbankAccount implements AccountService {

	// references
	public void setStockQuoteService(StockQuoteService stockQuoteService) {
	   account.setStockQuoteService(stockQuoteService);
	}
	// properties
	public void setCurrency(String currency) {
	   account.setCurrency(currency);
	}

	private AccountServiceImpl account;
	private AccountDataServiceImpl accountData;

	public BigbankAccount() {

	   // Account component
	   account = new AccountServiceImpl();
	   // wire
	   account.setAccountDataService(accountData);

	   // AccountData component
	   accountData = new AccountDataServiceImpl();
	}

	public AccountReport getAccountReport(String customerID) {
	   return account.getAccountReport(customerID);
	}
}
      

Listing 4 is the Spring bean assembly for the bigbank_account composition. This is shown to illustrate the point that a Spring assembly can be used as a coarse-grained component implementation.

                
<beans 	xmlns="http://www.springframework.org/schema/beans"
		xmlns:sca="http://www.springframework.org/schema/sca"  ... >
 
 <sca:service name="Account" type="bigbank.account.AccountService" target="Account"/>  
 <sca:reference name="stockquote" type="bigbank.stockquote.StockQuoteService"/>

 <bean name="Account" class="bigbank.account.AccountServiceImpl">
   <property name="accountdata" ref="AccountData"/>
   <property name="stockquote" ref="stockquote"/>
   <sca:property name="currency" type="java.lang.String"/>
 </bean>

 <bean name="AccountData" class="bigbank.accountdata.AccountDataServiceImpl"/>

</beans>
      

Resources

Learn

• Get more information in the OASIS SOA Reference Model [PDF].
  
  
• Check out the SCA Assembly Specification.
  
  
• Learn more about the Spring Framework.
  
  
• See search results for coarse grained on Wikipedia.
  
  
• The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
  
  
• Stay current with developerWorks technical events and webcasts. Check out the following SOA and Web services tech briefings in particular:
  • Get started on SOA with WebSphere's proven, flexible entry points
  • Building SOA solutions and managing the service lifecycle
  • SCA/SDO: To drive the next generation of SOA
  • SOA reuse and connectivity
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Check out a quick Web services on demand demo.
  
  

Get products and technologies

• Innovate your next development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs, including the following SOA and Web services-related blogs:
  • Service Oriented Architecture -- Off the Record with Sandy Carter
  • Best Practices in Service-Oriented Architecture with Ali Arsanjani
  • WebSphere® SOA and J2EE in Practice with Bobby Woolf
  • Building SOA applications with patterns with Dr. Eoin Lane
  • Client Insights, Concerns and Perspectives on SOA with Kerrie Holley
  • Service-Oriented Architecture and Business-Level Tooling with Simon Johnston
  • SOA, ESB and Beyond with Sanjay Bose
  • SOA, Innovations, Technologies, Trends...and a little fun with Mark Colan
  
  

About the authors

Michael is responsible for the Service Component Architecture (SCA) programming model development. He has 18 years of experience in tools, connectors, and programming models.

Dave is a coauthor of the Service Component Architecture (SCA) specifications. He has 19 years of experience in operating systems and middleware. He's an STSM, SCA architect on the IBM WebSphere Application Server Development team.

Mike Edwards is a strategist working on emerging technologies in the area of SOA, particularly Service Component Architecture. He is the co-chair of the OASIS SCA Assembly technical committee and a committer on the Apache Tuscany project, which implements an SCA run time for components written in a variety of languages.

Eric Herness is an IBM Distinguished Engineer and is the Chief Architect for Business Process Management (BPM) and WebSphere Business Integration products in the AIM Division of the Software Group. Eric is a senior member of the WebSphere Foundation Architecture Board and a member of the Software Group Architecture Board Steering Committee.

Stephen Kinder is a Senior Technical Staff Member and is the lead architect for the delivery of Service Component Architecture in WebSphere Application Server. He has worked for IBM for 20 years and has been involved in WebSphere products for 10 years.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Overview
• Functional characteristics of components
• Nonfunctional characteristics of components
• SCA programming model details
• Inventory of component technologies
• Summary
• Appendix
• Resources
• About the authors
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers