Injection of JPA Entity Manager Factory/Entity Manager

The injection of JPA Entity Manager Factory/Entity Manager would allow sharing of EMFs across multiple components, this would be useful in scenarios where you have conversation. In this case, the runtime would be responsible for making sure the EM would be created and closed transparently for the application developer based on the conversation.

JPA Data Services

In this case, we would be extending the SCA programming model to expose services that interact with a persistent layer in a declarative fashion hiding the implementation details from the service developer.It's all about simplicity, allowing a service to be defined without explicitly coding the persistence layer. This would be a new Tuscany Component Type named Implementaiton.JPA. A developer would provide the business objects that would by JPA to do the OR mapping, and a business interface that would be introspect by Tuscany to properly make the JPA calls to the persistence layer to retrieve the information. Information on how to connect to the data source would be done in the composite, and we could provide some annotations to read

Business Object

The business object can be defined as per JPA programming model. You can define it as a JPA Entity and make use of JPA annotations, or use the ORM.xml as well.

@Entity
public class Customer {

    @Id    protected int id;
    @Basic protected String name;
    @Basic protected String phone;

    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getPhone() {
        return phone;
    }

    public void setPhone(String phone) {
        this.phone = phone;
    }
}

Business Interface

The Business interface would define the access to the JPA entities, and we would introduce Java Annotations to bind a specific method to a JPA query.

import org.osoa.sca.annotations.Remotable;

@Remotable
public interface CustomerService {

    Customer[] getCustomers();

    void setCustomer(Customer customer);

    @Query(SELECT c FROM customer c WHERE c.name = '" + $1 + "'")
    Customer queryCustomerByName(String name);

}

We would use some Convention over Configuration to bind the interfaces methods to proper database activities :

Note that introspection will be required by the runtime to properly identify the operation type being requested. Based on this introspection, the runtime will also be responsible for any necessary conversion to the proper collection being expected as a result.

Composite

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
     xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
     targetNamespace="http://sample/implementation.jpa"
     name="customer">

	<component name="CustomerServiceComponent">
		<tuscany:implementation.jpa>
			<tuscany:persistence-unit name="customer">
				<tuscany:class>assets.Customer</tuscany:class>
			</tuscany:persistence-unit>

                <tuscany:connectionInfo>
		      <tuscany:connectionProperties
			   driverClass="org.apache.derby.jdbc.EmbeddedDriver"
			   databaseURL="jdbc:derby:target/test-classes/customer; create = true"
			   loginTimeout="600000"/>
	        </tuscany:connectionInfo>
		</tuscany:implementation.jpa>
	</component>

</composite>

Benefits

• Simplify the programming model for accessing data, hiding some of the API details required for this kind of components
• Allow exposing data services trough multiple SCA Bindings (e.g ws, json-rpc, feeds, etc)