Typical composite applications
involve integration amongst a variety of source and target systems, including
but not limited to messaging systems such as AQ or MQ Series, Applications such
as e-Business Suite or Siebel, Databases, Custom applications, B2B partners
etc. Oracle SOA Suite 11g provides
connectivity to variety of such sources, and at the same time, enables users to
model complex business processes orchestrating messages amongst these systems
in an Agile fashion.
Java incarnates at several points
within most of these integration projects. They could manifest as existing Java
Assets that you may need to converse with – such as EJBs or POJOs, as utility
components that you need to callout to process complex financial algorithms, or
as assets that you yourself need to build during the integration to handle business
or system errors.
It is imperative to understand
the different options in hand while designing integrations with Java or J2EE
components. You will be able to leverage the full potential of each option by exercising
them where they are a good fit, while understand the pros and cons that come
with it. This weblog entry discusses
these options in greater detail. Also discussed are various options to invoke
SOA Suite composites via Java.
Here are a few options that you
may consider while integrating with Java components.
Java embeddings are extremely useful while building small utility
snippets inline within BPEL
processes. This includes like regular expression processing, String
manipulation, Mathematical computations, invoking Java APIs to perform tasks on
the file system such as run windows tasks or execute batch scripts etc.
Java Embedding is a BPEL feature.
1) Provides inline access to Composite and component information,
and also BPEL variables.
2) Can add entries to BPEL audit trails from within the embedding.
3) Façade APIs available for easy DOM Manipulation.
1) Since Java embeddings are inline java code, they are inherently
non-reusable. If you plan to re-use the embedded functionality, java embedding
may not be a great idea.
1) Do not use to build complex
Business Logic
2) Limit the amount of code
within your embedding to avoid code maintenance and management overheads.
2) If invoking transactional
endpoints, the transaction is propagated into the target endpoint.
3) Do not use Java Embedding to
converse with the target systems of your integration. This will reduce the
visibility within your Enterprise Application and is considered a poor design.
4) Exceptions can be thrown and
treated as BPEL Faults.
Oracle SOA Suite Developer’s
Guide
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_java.htm#BABFCJDJ
1) You
can wrap your Java objects into XSLT or BPEL XPath extension functions when you
wish to leverage them within your data assignments, conditions, or XSL Mappings.
Most of these use-cases involve Java components that perform mathematical
computations, String manipulation etc, just like the Java Embedding does.
XSLT XPath functions can be used
within any XSLT within SOA Suite or OSB. Evidently, BPEL XPath functions can be
referred to only within BPEL processes.
1) Stateless Utility Code can be
converted into an XSL XPath function without any additional coding.
2) Promotes code re-use.
1) If
you have existing java components, you may need to build wrapper objects that
implement a specific BPEL Interface for them to be used as BPEL XPath extension
functions.
2) No security features are available when Java
components are exposed via XPath functions.
Notes
1) Do not use to build complex
Business Logic.
2) Do not invoke target systems
that you are integrating from within your XPath functions, since you will lose
visibility. This is generally a bad modeling approach.
One of the most widely used
deployments for Java components. Typically used when you need to expose java
assets as discrete Web Services, especially across firewalls - an important
use-case for SOAP.
SOA Suite
1) The Web Service can be managed
and maintained separate from the Business Process or the Integration.
2) Allows for clean contract
based conversations since the Service is based of the WSDL.
3) Can be registered in a
Registry/Repository
4) Can be virtualized using a
Service Bus.
5) Can be re-implemented in any
platform or programming language without impacting the calling services.
6) Can be secured, monitored and
tuned from the infrastructure level.
1) Object2XML conversions and
SOAP add additional overhead.
2) Not a great choice if you need
transactionality
3) Needs personnel who understand
JAX-WS stack to build, develop and maintain the services.
4) Requires client applications that
can communicate via HTTP.
1) JAX-WS allows for Async
conversations too.
SOA Suite
1) Native Java/RMI calls avoid
additional overhead introduced by SOAP.
2) When EJB Service w/Java
Interface is called from Spring components, avoids O2X conversion costs
1) Users may need to be well versed
with ORM and persistence technologies.
Oracle SOA Suite Developer’s
Guide
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/sca_sdo_ejb.htm#BAJBCFGE
1) When you want to expose your Java Components
as First Class Citizens in your SOA - allowing it to converse and exchange
messages with other Service components and SCA References. Thus useful when your Service component needs
to perform Java Processing as well as need to invoke a Mediator, BPEL, EJB or
another Web Service.
2) Useful if you have existing
assets such as Spring/Hibernate Applications that you want to bring into your
SOA.
3) Useful while migrating from
JCAPS to SOA Suite to wrap JCDs into Spring Beans.
4) Also useful while migrating
from WLI to SOA Suite for Custom Controls.
5) Do not use as a replacement
for other built-in components such as BPEL, Mediator or Adapter Services.
SOA Suite
1) Re-use of existing Assets
2) Enables use of Aspect oriented
programming declaratively within your POJOs.
3) Enables Auditing of your
Spring components via EM [Feature not available yet]
4) Can be secured via OWSM
policies.
5) Being a native service
component, easily integrates with other SCA Service and binding
components."
1) Can be exposed as a SOAP/HTTP
Web Service, or as an EJB.
2) The Java classes are packaged
within the Composite archive itself."
Oracle SOA Suite Developer’s
Guide
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/sca_spring.htm#BCGCJGDF
1) Useful
to implement Prologue and Epilogue style invocations to java code before and
after execution of routing rules in mediator.
2) Useful
to cleanse input/output XML payloads, or perform context specific logging.
This is a Mediator feature.
1) If
you have existing Java Assets that manipulate XML payloads before sending out
to partner applications, then you can directly re-use them within your Mediator
Java Callouts, as a faster alternative to building new XSLT maps.
1) No
Auditing/Visiblity into the Callouts
1) Need to implement a specific
Pre-defined Interface.
2) The Flow trail indicates a
preRoutingRule or a postRoutingRule being invoked.
Oracle SOA Suite Developer’s
Guide
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/med_createrr.htm#BGBDBHBE
1) Useful
if you need custom validation/transformation/security, or message enrichment in
your Bus pipelines.
2) Use
is preferable on inbound side.
3) Use
a custom transport instead of a Java Callout on the outbound side.
This is an OSB feature.
1) Simple interface to invoke
Java methods within a JAR resource.
2) Automatic type conversion for
parameters and return value.
3) Integrated lifecycle
management of SOA and Java (jar) resource.
4) Users can view the
POJO/Parameters from OSB Console/Design-time.
6) Use EJBs as Java Callout
targets when you need better management while accessing XA resources. However,
POJOs also allow propagation of transaction and security context.
7) POJO Must be thread-safe.
OSB User Guide:
http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/pojo.html
1) Primarily to integrate with existing or new EJB
assets, and provide transport mediation security, monitoring and alerting features
etc of OSB.
This is an OSB Feature.
1) Since EJB Transport provides JAX-RPC mapping, it
is useful when you wish to expose EJBs as SOAP/HTTP web service, or REST
endpoints that speak XML.
1) EJB Transport is an “Outbound-only” feature. You cannot expose a Service as an EJB via this
feature.
1) Very useful for native java integration. Typical
use-case would be when your client and service are both Java Applications.
This is an OSB feature.
1) Fully embraces XA and security semantics
2) Supports inbound and outbound interactions, as
opposed to the EJB transport, that supports only inbound.
1) Does not support Java2XML conversions.
1) Both EJB 3.0 and 2.1 supported.
1) Use-cases are similar to the OSB JEJB Transport –
native java integration. You could typically receive java objects onto the bus from
a JMS Topic [JMS MessageType = ObjectMessage] transport and then invoke a Java
Callout that can directly process these objects sans any conversations. Alternatively,
you could drop an JMS Object Message onto a JMS Topic using this feature.
This is an OSB feature
1) Locator
API
For you to use the Locator API,
ensure that you have an ADF binding (binding.adf) on your Service Interface. The
Locator API is very similar to what you have seen in SOA Suite 10g.
Hashtable
props = new Hashtable();
props.put(Context.PROVIDER_URL,
"t3://adc4100101a:7001/soa-infra");
props.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
props.put(Context.SECURITY_PRINCIPAL,
"weblogic");
props.put(Context.SECURITY_CREDENTIALS,
"weblogic1");
Locator
locator = LocatorFactory.createLocator(props);
Composite composite= locator.lookupComposite("default/SimpleApproval!1.0");
Service service = composite.getService("simpleapprovalclient");
String msg = “<input><msg>Hello World</msg></input>";
NormalizedMessage req = new NormalizedMessageImpl();
req.getPayload().put("payload", msg);
NormalizedMessage responseMsg = service.request("execute", msg);
Element respPL = (Element) responseMsg.getPayload().get("payload");
Oracle Fusion Middleware
Infrastructure Management Java API Reference for Oracle SOA Suite
http://download.oracle.com/docs/cd/E14571_01/apirefs.1111/e10659/toc.htm
2) Direct Binding API
Originally used for connectivity
between SOA Suite and OSB. The API also leverages the Locator API, but has
slight differences from the former. The developer’s guide has very good
examples illustrating how java clients can use Direct Binding API to invoke SOA
Composites. See link below.
Oracle SOA Suite 11g Developer’s
Guide http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/invocapi.htm#CHDBBBBC
3) Java
Web Services Proxy
You can generate a Java Web
Services Proxy [JAX WS or JAX-RPC] from within JDeveloper and invoke the SOA
Composite using SOAP/HTTP. Note that if
the SOA Web Service is secured via message level security or TLS, the proxy
should be updated to provide the credentials as appropriate.
Refer to JDeveloper documentation
for more information.
4) Adapter
Interface
Java components may interface
with SOA composites via file system, database tables, JMS Destinations etc. The
Java client may drop a file into a directory on the file system, or enqueue messages
into a JMS topic that is being polled by SOA composites (through Adapters) that
could then pick up the message and continue processing.
1. Fault
Handlers
You can configure to use a Java
Action within your Fault policies. These Java based Fault Handlers need to implement
a specific Interface. [Separate ones for BPEL and Mediator].In both cases, you
have access to the in-scope messages/variables for query/update.
See section 21.1.1.2 of SOA Suite
Developer’s Guide for details on Mediator Java Fault Handler.
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/med_faulthandling.htm#BABGFBCB
See section 11.4.3 of SOA Suite
Developer’s Guide for details of BPEL Java Fault Handler.
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_faults.htm#BABJIBJB
2. Sensor
Actions
You can configure the Publish target
of a Sensor Action to be a custom Java Class. You need to implement a specific
Data Publisher interface to be able to register as a sensorAction target. See
section 17.2.5 of the SOA Suite Developer’s Guide to see how.
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_sensors.htm#BABEBIFB
3. Custom
Workflow Clients
You can implement the Workflow Java
APIs to build a custom Worklist client.
See Section 30.3 of the SOA Suite
Developer’s Guide for more information.
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_worklistcust.htm#CIHJAHBJ
It would be useful to understand the performance impact of each case