-
Oracle SOA Suite
September 17, 2011
When Java Meets SOA
Overview
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.
Integrating with Java or J2EE Components
Here are a few options that you
may consider while integrating with Java components.
1. Java Embedding
When to use:
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.
Product
Support:
Java Embedding is a BPEL feature.
Pros:
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.
Cons:
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.
Notes:
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.
More Information:
Oracle SOA Suite Developer’s
Guide
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_java.htm#BABFCJDJ
2. Custom BPEL/XSLT XPath Functions
When to use:
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.
Product Support
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.
Pros
1) Stateless Utility Code can be
converted into an XSL XPath function without any additional coding.
2) Promotes code re-use.
Cons:
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.
More Information:
Oracle SOA Suite Developer’s Guide
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/bp_appx_functs.htm#BEIIAHJH
3) JAX-WS or JAX-RPC Web Services exposed using
SOAP/HTTP
When to use:
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.
Product Support:
SOA Suite
Pros:
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.
Cons:
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.
Notes:
1) JAX-WS allows for Async
conversations too.
4. EJB Services
When to use:
1) When you wish to
communicate with EJBs via a) SDO parameters [WSDL Based], or b) Java Interfaces
[no WSDL].
Product Support:
SOA Suite
Pros:
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
Notes:
1) Users may need to be well versed
with ORM and persistence technologies.
More Information:
Oracle SOA Suite Developer’s
Guide
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/sca_sdo_ejb.htm#BAJBCFGE
5. Spring
Component
When to use:
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.
Product Support:
SOA Suite
Pros:
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."
Notes:
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."
More Information:
Oracle SOA Suite Developer’s
Guide
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/sca_spring.htm#BCGCJGDF
6. Java
Callouts
When to use:
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.
Product Support
This is a Mediator feature.
Pros:
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.
Cons
1) No
Auditing/Visiblity into the Callouts
Notes:
1) Need to implement a specific
Pre-defined Interface.
2) The Flow trail indicates a
preRoutingRule or a postRoutingRule being invoked.
More Information:
Oracle SOA Suite Developer’s
Guide
http://download.oracle.com/docs/cd/E21764_01/integration.1111/e10224/med_createrr.htm#BGBDBHBE
7. OSB
Java Callouts
When to use:
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.
Product Support
This is an OSB feature.
Notes:
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.
More Information:
OSB User Guide:
http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/pojo.html
8. OSB
EJB Transport
When to Use:
1) Primarily to integrate with existing or new EJB
assets, and provide transport mediation security, monitoring and alerting features
etc of OSB.
Product Support
This is an OSB Feature.
Pros:
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.
Cons:
1) EJB Transport is an “Outbound-only” feature. You cannot expose a Service as an EJB via this
feature.
9. OSB JEJB Transport
When to use:
1) Very useful for native java integration. Typical
use-case would be when your client and service are both Java Applications.
Product Support
This is an OSB feature.
Pros:
1) Fully embraces XA and security semantics
2) Supports inbound and outbound interactions, as
opposed to the EJB transport, that supports only inbound.
Cons:
1) Does not support Java2XML conversions.
Notes:
1) Both EJB 3.0 and 2.1 supported.
10. JMS Transport
When to use:
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.
Product Support
This is an OSB feature
Invoking SOA Suite from Java Components
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"); More Information:
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.
More Information:
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.
Other Meeting points for Java and SOA Suite
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