SCA Java Client Model Ron Barack SAP

1
SCA Java Client ModelRon Barack - SAP

2
Agenda

• Scenarios
• Proposal
• Open Issues

3
Scenarios I Out-of-Container

• Client code running in a seperate VM
• Client wants to access services that are offered
  through SCA
• Why not use a binding?
• Client maintains a logical view of the services
  he is using.
• Services are configured centrally (e.g., through
  a deployed composite), not by the client.

4
Scenario II In-Container

• Same VM as the SCA Runtime
• New technology, but dont want first class
  integration (i.e., dont want to develop new
  implementation type).
• Allow the client technology to consume services
  while ignoring the cross-technology integration
  issues.
• First step towards full integration.

5
Agenda

• Scenarios
• Proposal
• Open Issues

6
Approach

• Dont define a new API, but provide access to the
  existing on. At a bare minimum, this means that
  the client must somehow obtain a ComponentContext
  object.
• The client is identified with a component, in a
  composite that is deployed
• P1 Locally
• P2 On the Server

7
P1 Client-Side Assembly

• Modeled after JEE Application Clients
• A lightweight container that allows the same
  programming model (and configuration) as is used
  on the container. In EJB, this means the client
  has deployment descriptors. For SCA, SCA
  Assembly (composite files) instead of deployment
  descriptors.
• Use a designated component as the source of the
  wires

8
Form of Client Assemblies

• Form of a client assembly
• Composite with a single component, and wires to
  other domain components.
• No exposed bindings or container implementation
  types.
• Can the client expose services?
• Can domain level bindings be used?
• The clients assembly is included into the
  domain.
• Client uses standard SCA programming model.

9
P2 Server-Side Assembly

• The client identifies itself as implementing a
  component in a contribution deployed on the
  server.
• Only components with a specific implementation
  type (implementation.client) allow this behavior.
• The client uses an (vendor specific?) SPI to find
  the ComponentContext, and uses this API to
  retrieve references, properties.

10
Amorphous component types

• Obviously, we cant derive the componentType
  through introspection!
• Fits every component configuration.
• The componentType is derived from the component
  configuration.
• If the assembly defines a reference, the
  implementation automatically has the reference.
• Also useful for frameworks, generically
  programmed implementations, etc.

11
Comparison P1 vs P2

• P1 fits better with scenario 1.
• P2 fits better with scenario 2.
• Both require some vendor extensions
• P1 How the client finds the domain
• This will probably require some additional
  descriptor.
• P2 How the client obtains the componentContext
• Should we standardize this API?

12
Agenda

• Scenarios
• Proposal
• Open Issues

13
How does Client Identify Component

• Vendor-specific SPI?
• At SAP we have
• SCAEnvironment.getInstance().getComponentContext(
  )
• How to identify the component?
• Through components QName?
• Through key in the implement.client tag?

14
Thank you!

• Questions?