1 / 23

SCA and Java

SCA and Java. SCA provides support for multiple Java-based component implementation types Java POJOs (implementation.java) Spring Beans (implementation.spring) EJB (implementation.ejb) Common annotations and API May be used by all Java-based implementations

lucius
Download Presentation

SCA and Java

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SCA and Java • SCA provides support for multiple Java-based component implementation types • Java POJOs (implementation.java) • Spring Beans (implementation.spring) • EJB (implementation.ejb) • Common annotations and API • May be used by all Java-based implementations • Metadata service contracts based on Java interfaces • Metadata component type information • Metadata container-component implementation contract • Asynchronous interactions and callbacks • APIs (few) for accessing assembly information

  2. An example Java implementation type • Just Java with a few (optional) annotations public class LoanServiceImpl implements LoanService { private CreditService creditService; public LoanServiceImpl(@Reference CreditService creditService) { this.creditService = creditService; } public void apply(Application application) { String id = application.getCustomerID(); int rating = creditService.getCreditScore(id); } }

  3. Key Principles • Simplify component development • Use POJOs • Minimal container coupling to implementations • Achieved through Inversion of Control or IoC • Simplify reuse through service-based design • Strongly defined contracts that pass data • Remove need to interact directly with binding protocols and transports most of the time • Focus on loosely-coupled interactions

  4. Metadata for Service Contracts • @Remotable • Defines a service that may be visible across process boundaries • @Conversational, @EndsConversation • Deals with conversational services • More on this later • @OneWay • Denotes a non-blocking operation • More on this later • @Callback • Defines callback interface and injection

  5. Metadata for defining component type information • @Service • Defines services offered by an implementation • @Property • Identifies a component type property • Setter-based, ctor-based and field-based injection supported • @Reference • Identifies a component type reference • Setter-based, ctor-based and field-based injection supported • SCA defines heuristics for unannotated POJOs as well

  6. Container-Component Implementation Contract Metadata • @AllowsPassByReference • Per-class or per-operation • @Scope • Specifies visibility and lifecycle contract • STATELESS (default), REQUEST, CONVERSATION, COMPOSITE • Containers may also add custom scopes • Conversation semantics • Always between two parties • May be long-running

  7. Asynchronous Interactions • @OneWay • Indicate a non-blocking call on an interface public interface Counter { int getCount(); @OneWay void increment(); @EndsConversation int reset(); }

  8. Callbacks • Stateful and stateless • Non-blocking or blocking @Callback(MyCallback.class) public interface MyService { void call(); } public interface MyCallback { void call(); } public class MyServiceImpl { @Callback public void setCallback(MyCallback callback){ //... } //... }

  9. Stateful Callbacks • LoanShark service Conversational @Callback(Borrower.class) public interface LoanShark { void borrow(double amount); @EndsConversation void payback(); @OneWay void delay(); } public interface Borrower { warn(); breakArm(); @EndsConversation kill(); }

  10. APIs • Only a few, deal with specific use cases, e.g. • Component context, name • Request contexts • Service references (may be passed) • Conversation id • Set callback

  11. www.oasis-open.org SCA - Spring Integration

  12. Spring • Spring application contexts can be used as component implementations • Spring beans can be wired to SCA or external services services • Spring beans can have services exposed • Other SCA components may be wired to them • Beans may be bound using an SCA binding Spring Beans SCA Service SCA Reference implementation.spring

  13. www.oasis-open.org SCA - Java EE Integration

  14. www.oasis-open.org Why SCA With Java EE Platform? Java EE gets • Additional implementation types and bindings on the application level: • BPEL, Spring,... • More to expect: For example ESB style interactions • Move protocol specifics to configuration via bindings • Cross-Application Assembly • Domain assembly extends Enterprise App Assembly to the cross-app level SCA gets • Reuse of existing assets, know-how, tooling.

  15. www.oasis-open.org Types of Integration • Bindings • JMS, Session Beans, JCA • Implementation Types • Java EE Components (SessionBeans, WebComponents, etc) asimplementation types. • Java EE Archives (EARs, WARs, EJB-JARs) as implementation types.

  16. www.oasis-open.org Use Cases for Bindings Binding.ejb • Consume session beans from service components • Expose SCA services as session beans, so that they can be consumed by unmodified Java EE components Binding.jms, Binding.jca • Several other binding types relate to Java EE, but are the focus of other working groups.

  17. www.oasis-open.org Use Cases for Java EE Components as Implementation Types • Java EE components use SCA‘s programming model to consume SCA-exposed services. • Use session beans as Service Component Implementations that may be consumed by other SCA components. • Use recursive SCA assembly in enterprise applications. • DeploySCA Components as a part of a Java EE application SCA is the Scale-Out model for Java EE

  18. www.oasis-open.org Use Cases for Java EE Applications as Implementation Types • Use Java EE applications as Service Component Implementations • Modified • Unmodified • Allow unmodified Java EE applications to be rewired by SCA. • Exposure of Java EE services at any level of recursive assembly. SCA is the level of assembly above Java EE

  19. Programming Model in JEE Components • Will be shown during demo:

  20. Contribution is JEE Archive:Sample Assembly I Composite with a session bean component <?xml version="1.0" encoding="UTF-8"?> <composite name="beancomposite" targetNamespace="http://www.sample.org" xmlns="http://www.osoa.org/xmlns/sca/1.0"> <component name="org.sample.Accounting"> <implementation.ejb ejb-link="module.jar#RemotableAccountingBean"/> </component> </composite>

  21. Contribution is JEE Archive:Sample Assembly II Including it into the domain Declare sample:beancomposite as Deployment Composite in In META-INF/sca-contribution.xml: <?xml version="1.0" encoding="UTF-8"?> <contribution xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:sample="http://www.sample.org"> <deployable composite=“sample:beancomposite"/> </contribution>

  22. Contribution containing a Java EE archive

  23. Open Questions • What is the componentType of an unmodified EAR (ie, one with no application.composite)? • Can ejb-ref‘s be rewired by SCA?

More Related