You may be thinking, oh great, not another programming model. What about Web services? What happened to Enterprise JavaBeans? Well, Service Component Architecture (SCA) is not meant to replace or compete with any existing programming models. Instead, SCA gives you a model to define interfaces, implementations, and references in a technology neutral way, letting you then bind these elements to whichever technology specific implementations you choose.
For example, we can define our interface in Java, and our implementation can be applied as a BPEL process, or we can have my interface as a WSDL document and our implementation could be a Java™ class. Out of the box, WebSphere Process Server lets integration developers have various different implementation technologies and enables you to expose the interfaces using open standards, such as with Java or WSDL. Additionally, SCA provides a client programming model that lets clients access service components. Developers are encouraged to keep developing using the various technologies they are familiar with, such as Enterprise JavaBean (EJBs), and use SCA to glue the components together.
Another major element of SCA is that it also defines a standard model for defining dependencies between components. As such, dependencies are defined by wiring SCA components together using references.
Finally, SCA defines a standard deployment model for packaging components into a service module. SCA components with their associated dependencies can be defined and packaged together into deployable units.