ORACLE SOA ESSENTIALS

1. SOA Essentials Cheat Sheet
Service Component Architecture (SCA)
SCA is a language-neutral component and assembly model being standardized as OASIS.
Composite: deployment unit specified by composite.xml e.g. think ejb-jar.xml
Component: abstract business logic with local services/references, configured by implementation e.g. bpel
Service: entry-point into composite, provides interface (ONE port type) and how to bind e.g. binding.ws
Reference: refers to external services and how to bind e.g. binding.ejb or binding.jca
Wire: connects services, components and references
Physical dependencies between SCA components injected at runtime via Spring Bean IOC framework.
Metadata Services (MDS)
Shared platform service to store and share all kinds of metadata artifacts e.g. WSDL, XSD, EDL, fault policies, bindings etc. SOA
uses MDS to store the exploded SAR file and platform configuration – service engines, binding components and soa-infra.
Physical store (PSTORE) can be a file system (used in development) or database (used in production).
Partitions are logical grouping of artifacts, normally tied to a single application e.g. soa-infra and owsm.
Namespace maps to a store and partition e.g. /policies for owsm partition or /apps for soa-infra partition.
Locations
o Applications specify the MDS location in the <metadata-store-usage> element of ./adf/META-INF/adf-config.xml
o File based MDS structure is <Store_Root>/<Partition>/<Namespace>/<Resource>
o For SOA shared artifacts, the namespace always starts with /apps and accessed via oramds:/<Namespace>/<Resource>
o For SOA exploded SARs, the namespace is /soa/deployed-composites
o File Store MDS Location is $JDEV_HOME/jdeveloper/integration/seed
o Database MDS Location is <prefix>_mds e.g. dev_mds
o File based MDS structure is <Store_Root>/<Partition>/<Namespace>/<Resource>
o Composite Distinguished Name is <domain>/<compositeName>!<revision>*<MDSlabel> e.g. default/OrderDemo!1.0_2013-03-04_12-23-10_112
Deployment
o Package all content in /apps to a resource jar file and add it to a zip file e.g. shared-mds.zip
o Use ant target “deploy” defined within ant-sca-deploy.xml
o Alternative: Use WLST script below
$MW_HOME/$SOA_HOME/common/bin/wlst.sh
wls:/offline> connect('weblogic', 'welcome1', 't3://localhost:7001')
wls:/soaDomain/serverConfig> sca_deployComposite('http://localhost:7001','D:MDSsoaappsshared-mds.zip',
overwrite=true
Metadata Manager
Provides an abstraction layer over MDS. Used to access SE/BC composite associated resources. One instance per composite.
CompositeModel.getMetadataManager()
MetadataManager.getDocumentAsDom()/Stream()
Fabric
SOA runtime infrastructure provides component lifecycle
management, normalized message bus, binding independent
policy enforcement, instance tracking and fault handling. Service
Engines (SE) e.g. BPEL, are containers for hosting business logic i.e.
composite components. Binding Components (BC) e.g. JCA/EJB,
encapsulate network protocols and translate to/from Normalized
Messages (NM).
soa-infra Startup Sequence
Spring Framework acts as the “kernel” for Fabric, boots from
fabric.war/WEB-INF/web.xml.
1. Spring initialization (fabric-config.xml), registered as
Context Listener with web container, instantiates SE and BC
2. Fabric Provider Servlet initialization, exposing the <service>
elements – uses the Oracle JRF Web Services provider
3. Fabric inititalization, deploys composites, <component>
definition to SE and <service>/<reference> to BC

2. Page 2
oracle.com/SOA blogs.oracle.com/SOA @OracleSOA OracleSOA Oracle SOA© 2013 Oracle Corporation. All rights reserved.
Service Engine/Binding Components
Lifecycle Methods (executed Right to Left on Composite)
 deploy(component), undeploy(component)
 load(component), unload(component)
 init(component), uninit(component)
 stateChanged(component)
 Initial Deployment: deploy()  load() init()
 Server Restart: load() init()
 Server Shutdown: uninit()  unload()
 Undeployment: uninit()  unload() undeploy()
Message Processing Methods
 Sync: NM request (NM, Operation, IC)
 Async: void post (NM, Operation, IC)
NormalizedMessage (NM) is based on an abstract WSDL.
InvocationContext (IC) allows the mesh to route NormalizedMessage.
Stores information from original context to create callback context.
Message Routing
 Composite execution request received FabricProviderServlet::doGet()/doPost()
 Delegates to FabricProvider.processMessage() – the JRF implementation
 Invokes EntryBC WebServiceEntryBindingComponent.processIncomingMessage()
 WS Entry BC builds Normalized Message (NM) from SOAP, identifies operation/callback
 WS Entry BC invokes Mesh.post()/request() based on One-way or Request-Response
 Mesh replies with SOAP response (if applicable) and uses InvocationContext (IC) to route
 Mesh calls composite associated message router MessageRouter.post()/request()
 MessageRouter holds composite reference – the source of truth of routes
 MessageRouter leverages message handlers: (A)/SynchronousMessageHandler
 Handlers identify target SE/BC and send message ServiceEngine.post()/request()
 For synchronous calls, SE/BC packages the output into the return NormalizedMessage
 For asynchronous calls, SE/BC creates callback context using message InvocationContext
 External WS BC leverages JRF based JAX-WS to dispatch outbound SOAP messages
 Local composite invocation skips HTTP/SOAP if same server and supported policies
Composite Packaging and Deployment
DeployerHTTPClient
JDeveloper, Ant or WLST client that initiates the composite deployment request.
Phase 1: Compile
 Syntax Validation
 Semantic Validation
 Validation process delegates to
each ComponentValidator
Phase 2: Package
 Create one SAR from each validated composite
 sca_<compositeName>_rev<revision>.jar
 Create MAR from metadata
 Dependent libraries in SCA-INF/lib
 Multiple application projects packaged in one zip file
Phase 3: Deploy
 Targeted to Managed Server
 SAR + MAR zipped along with action instructions
in deploy_info.xml
 HTTP POST zip file to CompositeDeployerServlet at
http://<server>/soa-infra/deployer
CompositeDeployerServlet
Performs deployment requests, receives the inbound zip file with SARs, unpacks it to a temporary directory and applies configuration plans, transfers
content to MDS and labels it, triggers deployment by invoking CompositeDeploymentCoordinator.
CompositeDeploymentCoordinator
Orchestrates composite deployment, re-deployment, undeployment for standalone and cluster deployments (uses Coherence). In the Prepare phase, calls
deploy()/load() on each Reference, Service Engine, Service from R to L. In the Activate phase, calls init() on each Reference, Service Engine, Service
from R to L. JMX MBeans to orchestrate property changes, policy reference changes. Updates deployed_composites.xml in XML.
CompositeDeploymentManager
Performs the composite deployment, re-deployment, undeployment. Interacts with a DeploymentResourceManager to obtain a deployment “connection”,
where the actual deployment functions are executed.
Event Delivery Network (EDN)
An integral part of SOA Suite that enables a loosely coupled, publish-subscribe style infrastructure to simplify message delivery. It uses the concept of
Event Definition Language (EDL) to describe the event, similar to WSDL. Underlying implementation can be based on Advanced Queues or JMS.
Publication happens using either Java or PL/SQL API. Subscribing composites are notified by EDN when a message arrives that matches the subscription
QName and optionally a content-based filter. Subscription consistency may be Guaranteed or Once And Only Once Delivery (OAOO) consistency. Guaranteed
uses local transactions and may deliver the message more than once. In OAOO mode, for each subscriber, EDN re- enqueues the message to the
EDN_OAOO queue and initiates an XA transaction.