SOA for the java developer, a focus

Especially for Patchset 2 of SOA Suite 11g we have put a focus on java development and the developer, which might not have skills to employ WSDL / XSD or XML every day, yet still wants to use the platform for monitoring, versioning and what not.

• Support for <interface.java/> as a first class citizen next to <interface.wsdl/>

<service name="IInternalPartnerSupplier">
  <interface.java interface="com.otn.sample.fod.soa.internalsupplier.IInternalPartnerSupplier"/>
</service>

instead of

<service name="externalpartnersupplier_client_ep">
  <interface.wsdl interface=http://partnersupplier.com/#wsdl.interface(ExternalPartnerSupplier)/>
</service>

This, kind of obviously, implies no need to create a WSDL in case you want to wire to an EJB / exposed Spring bean (via <sca:service/>) or want to expose a service Java friendly.

• Full support for Spring as component implementation (next to implementation.bpel, implementation.mediator, implemetation.rule and others).
  • A spring bean <beans:bean> can be exposed as component service <sca:service>
  • A (global) reference (composite reference) can be injected as into a bean, via <sca:reference>
  • Mapping between request / callback mep (pretty much a two portType model) and the spring implementation model (beans and references)
    • ComponentType
    • Spring beans context

    <!--  service mapping to above interface -->
    <sca:service type="com.example.AsyncInteractions"
          name="AsyncInteractions.AsyncInteractions" target="asyncBeanImpl"/>
    <!-- spring bean -->
    <bean class="com.example.impl.AsyncSpringComponentImpl" id="asyncBeanImpl">
          <property name="callback" ref="AsyncInteractions.AsyncInteractionsCallback"/>
    </bean>       
    <!-- reference mapping to the above callbackInterface -->
    <sca:reference type="com.example.AsyncInteractionsCallback"
          name="AsyncInteractions.AsyncInteractionsCallback"/>

    • Java bean implementation

    public class AsyncSpringComponentImpl implements AsyncInteractions
    {

      // injected by spring – this maps to the reference
      public AsyncInteractionsCallback mCallback = null;

      // implemented method from the interface
      public void process(String input)
      {
          // call the member (wired to the reference)
          mCallback.processResponse(("Hello" + input));
      }
    }

  <service name="AsyncInteractions.AsyncInteractions">
    <interface.java interface="com.example.AsyncInteractions"
                    callbackInterface="com.example.AsyncInteractionsCallback"/>
  </service>

• Native support for java objects (POJOs) across the platform
  • The mean of travel between components (hence service engines and binding components) is the normalized message (oracle.fabric.common.NormalizedMessage), modeled after an abstract WSDL (that is “type system”, headers, properties and messages)
    
    // SDO support
    void setSdoPayload(java.util.Map pPayloadMap, oracle.fabric.common.SDOMessageMetadata pSDOMessageMetadata);
    java.util.Map<java.lang.String, java.lang.Object> getSdoPayload();

  // Java object support
  void setJavaPayload(java.util.Map pPayloadMap);
  java.util.Map<java.lang.String, java.lang.Object> getJavaPayload();

  // xml payload support
  void setPayload(java.util.Map pPayloadMap);
  java.util.Map<java.lang.String, java.lang.Object> getPayload();

  • Each Service Engine can have a dependency on the payload type (e.g. BPEL is based on DOM xml), and while the “underlying” message is based on a pojo, upon calling “getPayload” we will do conversion to the target format on the fly.
• Support for EJB bindings (binding.ejb)
  • One notoriously weak point of Oracle SOA suite was the ability to connect / and use EJBs. Given that BPEL / OESB are based on XML the developer had to hand-craft (or partiallly generate the WSDL, and add binding / type mappings [and suffer through debugging it later on]) 

  <binding name="EJBBinding" type="tns:CreditRatingService">
    <ejb:binding/>
    <!-- create the type map -->
    <format:typeMapping encoding="Java" style="Java">
      <format:typeMap typeName="xsd:string" formatType="java.lang.String" />
      <format:typeMap typeName="xsd:integer" formatType="int" />
      <format:typeMap typeName="xsd:boolean" formatType="boolean" />     
    </format:typeMapping>
    <operation name="validateSSN">
    <!-- define the ejb mapping, including type ordering, method, parts -->
      <ejb:operation
         methodName="validateSSN" parameterOrder="ssn" interface="remote"
         returnPart="status" />
      <input name="ValidateSSNRequest"/>
      <output name="ValidateSSNResponse"/>
    </operation>
  </binding>

  • In 11g we added a full fledged in- and out-bound ejb binding, based on interface.java

  <reference name="IExternalPartnerSupplierService">
    <interface.java interface="externalps.IExternalPartnerSupplierService"/>
    <binding.ejb uri="ExternalLegacyPartnerSupplierEjb#com.otn.sample.fod.soa.externalps.IExternalPartnerSupplierService"
        javaInterface="externalps.IExternalPartnerSupplierService" ejb-version="EJB3" />
  </reference>
  
  So no more pain with XML to Java serialization and back, if needed the platform does it for you

• Invocation of a composite service
  • Composite service via <binding.ejb/>
    • A composite service (based in interface.java) can be exposed as ejb. At that point you can use standard jee tooling and APIs to create a remote proxy
  • Locator API
    • The locator API can be used to query composites, their state, and also do administration. In PS2 we consolidate the mbean API (which is the admin part) and the query API (which is around the locator). At that point we are enpar with the API we had in 10.1.3.x  (SOA Suite 10g)
  • Direct Binding API
    • In order to allow high performance invocation of a composite service (and also the ability to be called back from the service) – we added a new API called direct binding. More information and a sample that shows the usage can be found here