Ramkumar Menon

Subscribe to Ramkumar Menon feed
Principal Product Manager
Updated: 11 hours 30 min ago

Oracle SOA Suite Adapters and B2B Training - Register now!

Tue, 2013-07-23 23:15

Scott Haaland and I are delivering a SOA Suite 11g Adapters and B2B training as a part of the Oracle Fusion Middleware Summercamp III event  between August 26-30 between August 26-30 at Lisbon, Portugal.  Register now!  More details,including registration are available from our SOA Community page at http://soacommunity.wordpress.com/2013/07/16/soa-suite-11g-b2b-adapters-training-august-26th-30th-2013/

Oracle A-Team Chronicles Live!

Fri, 2013-06-07 13:58
Oracle Fusion Middleware A-Team is Oracle' SWAT Team of Solution Architects with extensive expertise in Oracle's Integration Product Stack. Their new Chronicles Portal is live at http://www.ateam-oracle.com/integration/. It contains several articles describing Best Practices, Tips & Tricks, Architectural Guidance for SOA, BPM, and several other subjects. Its a Must-Bookmark Portal. Happy Reading!

E-Business Suite Adapter vs Integrated SOA Gateway

Wed, 2012-11-28 17:52

Snip from a very Nice Slide Deck from a Presentation by the E-Business Suite Team.

See the entire presentation here


Adapters, SOA Suite and More @Openworld 2012

Sun, 2012-09-30 02:46

You are invited to attend my sessions at Oracle Openworld 2012 at San Francisco!

Session Speakers:
Ramkumar Menon, Francis Ip
Session Schedule: Monday, Oct 1, 1:45 PM - 2:45 PM -

Session Location: Marriott Marquis - Salon 7

CON8642 - Cloud and On-Premises Applications Integration using Oracle Integration Adapters

Session Speakers:
Vikas Anand, Ramkumar Menon, Stephen Mcritchie

Session Schedule: Wednesday, Oct 3, 1:15 PM - 2:15 PM

Session Location: Moscone South - 310

And do stop by at the Oracle Integration Adapters Demo booth. Watch some live demos on how you can use our suite of Adapters to integrate and extend your Enterprise Applications! This is your opportunity to meet with our Engineering team, share with us your Integration use-cases and challenges, and hear from us on our Roadmap.

The Oracle Integration Adapters booth is located at the Fusion Middleware Demopod area  from Monday, October 1 through Wednesday, October 3, 2012.

Handling Large Payloads in SOA Suite 11g

Fri, 2012-07-27 02:45

I delivered this session at ODTUG '12 where I talked about various considerations and product features that you should know when you are working with processing large payloads with Oracle SOA Suite 11g. You can find the deck for the session at

http://www.oracle.com/technetwork/middleware/soasuite/learnmore/binarycontentlargepayloadhandling-1705355.pdf

You are also welcome to share your experiences in this area.

What are the JCA Adapters that are officially supported to work with Oracle Service Bus 11.1.1.6?

Thu, 2012-05-03 16:58

Refer to Section 25.2.1 of the Oracle Service Bus Developer's Guide. Excerpt from the section inlined below.

Technology Adapters

1. Custom JCA adapters
2. Oracle JCA Adapter for AQ
3. Oracle JCA Adapter for Database
4. Oracle JCA Adapter for Files/FTP
5. Oracle JCA Adapter for Sockets
6.Oracle BAM Adapter (Business Activity Monitoring)

Application Adapters

1. Oracle Adapter for Oracle Applications.
2. PeopleSoft (Oracle Application Adapters 10g)
3. SAP R/3 (Oracle Application Adapters 10g)
4. Siebel (Oracle Application Adapters 10g)
5. J.D. Edwards (Oracle Application Adapters 10g)

GC Tuning Tips for your FMW

Thu, 2012-03-29 12:24
Rupesh is one of our in-house JVM Experts and has a valuable blog-entry on GC tuning here.

Select for update, nowait, skip locked

Wed, 2012-03-28 13:20

Our DB Adapter uses Skip locking to enable distributed polling - one of the ways to scale up your inbound db processing. I thought I would illustrate at a very high level how select for updates in general, and skip locking work.


New Oracle SOA Support Blog

Fri, 2012-03-09 00:02
Check out the new Oracle SOA Suite Proactive Support Team blog at https://blogs.oracle.com/soaproactive/

Easy Automation of common Weblogic and FMW Administration commands via WLST Recording

Fri, 2011-12-02 14:27

The WebLogic Scripting Tool (WLST) is a command-line scripting environment that you can use to create, manage, and monitor WebLogic Server domains. Weblogic Server provides you a way to record your configuration edits in the WLS Console as WLST scripts that can then later be edited and used for configuration automation. Note that for security reasons, it does not allow you to record all commands. Refer to the Weblogic Server documentation for what is disallowed.

Here is a simple run through of how you can use WLST recording and generate scripts for config automation. In this example, we will record the creation of a simple JDBC resource via WLS Console and edit it post-recording.

Step 1: Log into WLS Admin Console and click on “Preferences” at the top and click on the “WLST Script Recording” tab.

This page gives you details on where the script will be generated post recording, and the name of the file. You can change it to suite your needs.

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Calibri","sans-serif"; mso-bidi-font-family:"Times New Roman";}

Step 2: Click on “Start Recording” and then proceed to create the data source as shown in the steps later. This is under the assumption that Automatic Recording is turned off. In this case, you can start and stop recording when you have finished atomic recording tasks. Once you start recording, you can see a message indicating that the recording is on.


Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Calibri","sans-serif"; mso-bidi-font-family:"Times New Roman";}

Step 4:Once you have completed the configuration, you can click on “Preferences” at the top to come back to the Recording settings page and stop the recording. You can see that the recording window has captured all configuration changes in Jython format.

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Calibri","sans-serif"; mso-bidi-font-family:"Times New Roman";}

Step 5: Click on “Stop recording” to generate the file at the desired location.



Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Calibri","sans-serif"; mso-bidi-font-family:"Times New Roman";}

Step 6: Next, you can update the script to pass them as command line arguments or read them from a property file. See below.

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Calibri","sans-serif"; mso-bidi-font-family:"Times New Roman";}

Step 7: WLST can be run in a variety of ways. One way is to set the environment using wlserver_10.3/server/bin/setWLSEnv.sh and then running

java Weblogic.WLST scriptName.py.

Refer to the WLST documention for other means to execute WLST [Interactive, Embedded, Ant etc].

Processing Binary Data in SOA Suite 11g

Thu, 2011-11-17 12:16

SOA Suite 11g provides a variety of ways to exchange binary data amongst applications and endpoints. The illustration below is a bird's-eye view of all the features in SOA Suite to facilitate such exchanges.

Handling Binary data in SOA Suite 11g Composites

Samples and Step-by-Step Tutorials

A few step-by-step tutorials have been uploaded to java.net that illustrate key concepts related to Binary content handling within SOA composites. Each sample consists of a fully built composite project that can be deployed and tested, together with a Readme doc with screenshots to build the project from scratch.

For detailed information on binary content and large document handling within SOA Suite, refer to Chapter 42 of the SOA Suite Developer's Guide.

Handling Binary data in Oracle B2B

The following diagram illustrates how Oracle B2B facilitates exchange of binary documents between SOA Suite and Trading Partners.

Nice Introduction to WLDF Watch/Notifications

Fri, 2011-09-30 13:00

James Bayer has a simple hands-on video on setting up WLDF watches and notifications in WLS.

WLDF enables you to dump diagnostic images or send out JMX/Email notifications when any metric of your interest crosses a configured threshold. There's more to it, but here is a good start that will catch your interest!

http://www.youtube.com/watch?v=QNtON5dcRTcv

When Java Meets SOA

Fri, 2011-09-16 21:22
Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Calibri","sans-serif"; mso-bidi-font-family:"Times New Roman";} 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

Spring Framework Samples

Wed, 2011-09-14 18:09

You can leverage Spring Framework to integrate components that use Java interfaces into SOA composite applications. Oracle SOA Suite uses the spring framework functionality provided by the WebLogic Service Component Architecture (SCA) of Oracle WebLogic Server. In this weblog entry, you can find a few Spring Component samples that you may find useful. Each of the given sample contains a README that provides step-by-step instructions for developing and testing the Composite, along with a complete JDeveloper project that you can deploy and test directly. More samples will be made available soon. Please provide feedback on what specific features you would like to see within upcoming Spring samples.

1) Hello World - A simple composite with a Hello World style Spring Component

2) Spring calling BPEL - Sample illustrating how you can call a BPEL Process from Spring.

3) Spring AOP - Sample illustrating how you can use dynamic proxies to achieve AOP with Spring.

4) Predefined Spring Beans - Sample illustrating how you can use the predefined beans within SOA Suite to process headers, access composite information, or just perform context-aware logging.

5) Global Spring Beans - Sample illustrating how you can expose a simple POJO as a global spring bean that you can access within any SOA composite.

Is Local Optimization kicking in your WS Binding?

Thu, 2011-04-28 09:12

As we know, WS bindings are local-optimized as long as the Server URL configuration for your soa-infra matches your invoked endpoint. To check if local optimization is actually kicking in, you can wither
a) Chek your HTTP access log to see if calls are going over HTTP.
b) Set the the logger for oracle.integration.platform.blocks.soap.WebServiceExternalBindingComponent to FINE (TRACE:32). If local optimization is kicking in, you should be able to see logging messages such as "Invoking service request locally..." in your log files.

Oracle SOA Suite and BPM Suite VM [Oracle Virtual Box]

Wed, 2011-04-06 13:39

Just in case you missed to notice, you do have this all-in-one Box that runs SOA Suite, BPM Suite, B2B and BAM, right on OTN.
Click here for the download link.

Take a look at this entry in Antony Reynold's blog for getting started on this.

Enjoy!

 

 

Oracle Enterprise Manager FMW Control versus Oracle Enterprise Manager Grid Control

Wed, 2011-04-06 11:34

I have had questions from customers on what comes extra within our EM Grid Control offering above and beyond our EM FMW Control.

EM FMW Control 11g is for managing and monitoring one single FMW Farm/ WLS Domain. If your topology comprises of multiple FMW Farms/Weblogic domains, you cannot use a single FMW Control to manage all of them at one place.

This is where EM GC 11g adss value. Apart from being a single management and monitoring portal for several FMW farms, EM GC 11g also allows you to monitor and manage non-middleware software such as OS resources, JVM, Database. With access to much more metrics than the EM FMW Control, it adds more value in Diagnosability and End to End Visibility.
Please refer to this link for details.

 

Neighboring Siblings?

Wed, 2011-02-16 09:30

 

Found an Interesting observation on C.M.Spielberg McQueen’s Blog – XPath 1.0 describes, amongst other axes, ones that allow access to immediate parent and immediate child nodes, as well as access to ancestor and descendant node-sets, but does not provide for immediate siblings – The only way to access these are via predicates – preceding-sibling::*[1] or following-sibling::*[1], and not explicit next-sibling and a previous-sibling axes.

 

XML Schema 1.1 &ndash; What you need to know

Wed, 2011-01-19 11:02

Motivation

XML Schemas, more popularly known as XSDs, provide us a way to describe structure and content of XML Documents. Managed by W3C's XML Schema WG, a part of the XML Activity Group, XML Schemas evolved out of the shortcomings of its simpler and light-weight non-XML predecessor - DTDs, as well as through discussions and conferences of various interest groups across the community. The first W3C Recommendation of the XML Schema specification was released on 2 May, 2001.  The initial edition provided the users a strong type system, enabled users to model rich and complex structural constraints and value-spaces, recognized and allowed expression of namespaces, and also defined the intended behavior of Schema aware processors. This was followed up with a Second Edition in 2004, which wasn't really a newer version, but a minor errata driven release to the First Edition.

While XML Schemas matured, so did other XML based specifications like XSL, XQuery, Web Services, XPath, and several others . The XML Schema WG also ensured that these dependencies feed into the requirements for future versions of the language. The WG also provided an email distribution list that allowed developers and architects alike to exchange ideas, discuss issues and shortcomings, providing an open platform for debating the current and direction of the standard's future.  XML Schema 1.0 provided a platform that allowed architects in W3C and outside to clearly think about what is the next right step towards a "Version 2".

In 2005, W3C conducted a workshop on XML Schema 1.0 user experience. This workshop brought together users, developers and vendors into an open dialogue on potential usability issues, inter-op concerns and set the stage for a future version of the specification that addresses these glitches while adding in "must-have" features that were missed in 1.0. The key takeaways from all the following discussions were features related to Extensibility, Versioning and Validation. Apart from these, there were several very specific schema semantics that were long awaiting a change since 1.0 Ed2.

These led to the birth of a newer 1.1 version of the specification, which will be discussed in greater detail within this article.

Current Status of the Specification

The WG has released two Candidate Recommendation drafts of the following documents

The WG also released a non-normative guide to versioning XML Languages using new features of XML Schema 1.1.

Guide to Versioning XML Languages using new XML Schema 1.1 features

There are few key early implementers of the latest version of the specification namely Apache Xerces and SAXON.

Key Changes since 1.0

The changes since version 1.0 till date can be grouped into the following.

  • Validation
    • Rule based Validation - Love Schematron? 1.1 enables users to express cross-field validations and constraints using XPath 2.0.
  • Extensibility and Versioning
    • Wildcard Enhancements
      • Weak wildcard support - XSD 1.0 uses Unique Particle Attribution rule (UPA) to avoid ambiguity associated primarily with the usage of wildcard content. UPA restricts users from defining certain complex content models. XSD 1.1 attempts to address this using Weak wildcards that disambiguate using precedence rules.
      • Negative Wildcards and Multiple Namespaces
      • Open Content
    • <xsd:all> Model Group Changes  - Finally!
    • Vendor Unique Extensions - Enables vendors to ship their own primitive datatypes and facets
    • Conditional Inclusion - Enable creation of extensible schemas.
  • Miscellaneous Enhancements
    • Conditional Type Assignments
    • Inherited Attributes
    • Default Attribute Group - Enable globally shared set of attribute definitions.
    • Substitution Group Enhancements - Multiple element substitution related changes.
    • ID related changes - Enables, amonst others, mutliple ID attributes for elements.
    • Redefine Replaced by Override - Richer overrides, more interoperability.
    • Target Namespace attribute on local elements and attribute declarations
  • New Datatypes and Facets

One significant aspect of the standard that has been kept unchanged across revisions and editions is the Namespace URI for the schemas. What this means is that the version 1.1 schemas that you create will have the same XSD Namespace URI as a version 1.0 schema.

http://www.w3.org/2001/XMLSchema

In addition to this, almost all of the features in 1.0 have been brought into 1.1 in order to ensure backwards compatibility. What this means is that an XML document defined using a 1.0 schema can be validated using a 1.1 schema processor/validator.  This backward compatibility also ensures that the specification can satisfy dependant requirements from other specifications that rely on syntax and semantics of the 1.0 version of the specification.

1. Validations Rule based Validation

XML Schema 1.1 introduces a new Schema component named <assert> to facilitate rule based validation, along similar lines of Schematron.

User can specify an Boolean XPath expression that will result in the assertions to pass or fail, depending on the evaluation of the expression. Assertion failures are equivalent to a  non-assertion validation failure.

Example 1 <xsd:element name="priceRange">
  <xsd:complexType>
     <xsd:sequence>
         <xsd:element name="minPrice" type="xsd:decimal"/>
         <xsd:element name="maxPrice" type="xsd:decimal"/>
     </xsd:sequence>
    <xsd:assert test="minPrice le maxPrice"/>
</xsd:complexType>
</xsd:element>

In the above example, the assertion checks if the decimal value of minPrice element is less than or equal to the maxPrice element. If an instance document fails this assertion, that document is considered invalid w.r.t the Schema, just like a non-assertion validation failure would cause it to be.

Syntax and Namespace Scope

The asserts are always defined at the end of the type declaration. It can hold a valid XPath 2.0 boolean expression. Being related to XPath 2.0, users can leverage the XPath 2.0 specific functions and operators while building the assertions.

The context node used for the expression evaluation is always the element whose type declaration hosts the mentioned assertion. In the above example, the context node would be the priceRange element. Hence all expressions within the assertions will need to be relative to the priceRange element.

One key restriction that is imposed on the path expressions that can be modeled in an assertion is that one cannot refer to parent or ancestor nodes of the context node. Only context node, or any of its descendants can be referred to within the path expressions. Neither it's siblings nor it's ancestors are permitted.

By this rule, the following assertion is invalid.

<assert test="string-length(ancestor::order/id) > 0"/>

so is

<assert test="string-length(following-sibling::shippingDate)  > 0"/>

and so is

<assert test="doc('pub/docs/customers.xml')/customerInfo[2]/id='12345'"/>

Users can model as many assertions as they want on the type declaration. In that case, the instance document will be considered valid only if none of the assertions for that type declaration have failed.

The namespace scope of the path elements in the expression is determined by the value of the xpathDefaultNamespace attribute on the assert element. If the attribute is absent, its value is assumed to be ##local - which translates into null namespace. This attribute can also be declared to hold any URI, or alternatively configured to use the targetNamespace or the default namespace declared for the XML Schema.

Example 2

<assert test="tns:price > 0" xmlns:tns="www.oracle.com" xpathDefaultNamespace="www.oracle.com"/>

<assert test="price > 0" xpathDefaultNamespace="##targetNamespace"/>

<assert test="price > 0" xpathDefaultNamespace="##defaultNamespace"/>

<assert test="tns:price > 0" xmlns:tns="www.oracle.com" xpathDefaultNamespace="##targetNamespace"/>

<assert test="price > 0" xpathDefaultNamespace="##local"/>

<assert test="ns1:value > ns2:netValue" xmlns:ns1="www.oracle.com" xmlns:ns2="www.abc.com"/>

The last assert is equivalent to not having the xpathDefaultNamespace attribute at all.

Rule based Validation of scalar content

As we described above, <assert>s can be used to define rule-based constraints on complex content. In the event that one wishes to model rules for simple content - for instance, against elements of string or decimal datatype, one can use a new facet available for atomic datatypes - named <assertion>.

Original Declaration:
<element name="evenPriceChangePercent" type="decimal"/>

Declaration with assertion:
<element name="evenPriceChangePercent" type="evenPriceChangePercentType"/>
<simpleType name="priceChangePercentType">
  <restriction base="decimal">
       <assertion test="$value <= 100 and $value >= 0"/>
       <assertion test="$value mod 2 = 0"/>
  </restriction>
</simpleType>

As seen above, this facet provides a default "value" variable that holds the text content of the simple content used for the evaluation. You cannot access any other context nodes within the XPath expression.

2. Extensibility and Versioning Wildcard Related Enhancements Weak Wildcards

Wildcards were introduced into XML Schema to build flexibility into schemas that users build. One could build newer schemas that could validate instances that were defined using an older version of the schema [Backward compatibility], or vice versa [Forward compatibility]. XMLSchema 1.0 provided schema constructs like <any/> and <anyAttribute/> for this purpose. These constructs enable elements and attributes that aren't explicitly defined in the schema, to occur in a valid XML instance document, providing way for extensible content models.

For instance,

Example 3 <element name="Address">
  <complexType>
     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string"/>
          <!--allow any element from any namespace to occur -->
         <any namespace="##any" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

1.0 allowed for adding these wildcards at any position within your type declaration,as long as there isn't an ambiguity with explicitly declared elements.

Look at the example below.

Example 4 <element name="Address">
  <complexType>
     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
          <!--allow any element from any namespace to occur -->
         <any namespace="##any" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

With the above schema in mind, consider the following XML document.

Example 5 <Address>
   <street>1, Courthouse Square</street1>
  <city>Hill Valley</city>
  <state>CA</state>
  <zip>91919</zip>
</Address>

With this document, it is impossible to state if zip element should be associated with the named element zip, or the wildcard any element. This schema is thus prohibited in XML Schema 1.0. The rule that prohibits this is termed as Unique Particle Attribution (UPA) Rule.

With 1.1, the UPA restriction is relaxed - it is no longer forbidden to have the kind of XML Schema mentioned in Example 4. [competition between element and wildcard]. When there is such an ambiguity, the named element definition takes precedence. In this case, since there is an element named "zip" that can resolve the ambiguiity, that one is chosen over the wildcard during resolution.

Also considered legal is a competition between two wildcards. However, competition between two elements is still considered a violation of the rule.

For example, the following XML schema is still invalid since the processing application will not be able to disambiguate the <direction> element in the XML Instance if their respective siblings were absent.

Example 6 <element name="TimeTravel">
   <complexType>
      <choice>
      <sequence>
          <element name="direction" type="string"/>
           <element name="year" type="integer" minOccurs="0"/> 
      </sequence>
      <sequence>
          <element name="direction" type="string"/>
           <element name="universeName" type="string" minOccurs="0"/> 
      </sequence>
     </choice>
  </complexType>
</element>

Multiple Namespaces and Negative Wildcards

In XML Schema 1.0, you had the capability to specify the namespace URI for a wildcard element. You could either specify

  • A list of one or more specific URIs
  • ##other - which means any URI other than the targetNamespace
  • ##targetNamespace - which is self explanatory
  • ##any - which means any URI
  • ##local - which indicates null namespace.
Example 7 <any namespace="##other"/>
<any namespace="http://www.delorean.com http://www.fluxcapacitor.com"/>
<any namespace="##targetNamespace"/>
<anyAttribute namespace="##local"/.>

In XML Schema 1.1, you have more ways to control your wildcards. You could in fact state that your wildcards NOT come from a namespace UR or multiple Namespace URIs.

In addition to this, you can also constrain the potential qualified name of the wildcard through the new schema constructs.

Example 8 <any notQName="tns:Almanac tns:IceHockey"/>
<anyAttribute notNamespace="##targetNamespace"/>
<any notNamespace="##defaultNamespace"/>
<any notNamespace="http://www.fluxcapacitor.org"/>

Other constraints you can impose are:

  • Ensure your wildcards do not have the same name as any of it's siblings.
  • Ensure your wildcards do not have the same name as any of the existing global declarations in the schema.
Example 9 <any notQName="##definedSibling"/>
<any notQName="##defined"/>

Take a look at the schema below.

Example 10 <element name="Address">
   <complexType>
      <sequence>
           <element name="street" type="string"/>
           <element name="city" type="string"/>
           <element name="state" type="string"/>
           <element name="zip" type="string"/>
            <any notQName="##definedSibling" namespace="##local"/>
      </sequence>
  </complexType>
</element>

This will fail validation for the following XML instance.
<Address>
   <street>1, Courthouse Square</street1>
  <city>Hill Valley</city>
  <state>CA</state>
  <zip>91919</zip>
  <zip>94321</zip>
</Address>

Open Content

Open Content allows for defining elements to possess child element or attribute content other than the ones explicitly defined in it's content model, and allow them to be available at any position within its content.

In 1.0, you needed to explicitly position your <xsd:any/> declarations within your choice or sequence content models. In 1.1, you can declare open content for your elements at one place - within the complexType definition, or at the schema level. On top of this, you can choose to distribute your open content interleaved between your named child elements [interleaved], choose to have them after all of the child elements. [suffixed], or disable inherited openContent behavior.

Example 11 - Interleaved Open Content <element name="Address">
  <complexType>
    <openContent mode="interleave">
         <any/>
    </openContent>

     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

Valid Instances for the Schema

Example 1:

<Address>
   <street>1, Courthouse Square</street1>
   <boo/>
  <city>Hill Valley</city>
   <foo/>
   <bar/>

  <state>CA</state> 
  <zip>91919</zip>
   <boo2/>
</Address>

Example 2:

<Address>
   <street>1, Courthouse Square</street1>
   <boo/>
   <foo/>
   <bar/>
  <city>Hill Valley</city> 
  <state>CA</state> 
   <boo2/>
  <zip>91919</zip>
</Address>

Note that the maxOccurs="unbounded" and minOccurs="0" attributes on the <any/> is implicit - which explains how one is able to have multiple wildcard elements in your XML instance document.

Example 12: Suffixed Open Content
<element name="Address">
  <complexType>
    <openContent mode="suffix">
       <any/>
    </openContent>

     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

Valid Instance for the Schema

<Address>
   <street>1, Courthouse Square</street1> 
  <city>Hill Valley</city> 
  <state>CA</state> 
  <zip>91919</zip>
   <boo/>
   <foo/>
   <bar/>
   <boo2/>

</Address>

The third use-case - mode="none" is typically used when you are importing and extending a complexType from a foreign schema, but do not wish to inherit the openness of the inherited type definition.

The wildcard <any/> within the <openContent> section can be combined with the wildcard constraints discussed in the earlier section as well. [e.g. <any notQName="fc:doc"/>]

Another variant of of the openContent use-case is the one where user wishes to model adding wildcards within any element content defined in the schema - i.e. a schema-wide openContent.

This is supported through a schema construct <defaultOpenContent> declared as a direct child of the <schema> element. See example below.

Example 14 (I skipped "13") <schema targetNamespace="..." xmlns="....">
<defaultOpenContent mode="interleave" appliesToEmpty="true">
   <any/>
</defaultOpenContent>

<element name="Order">
  ....
</element>

<element name="Info">
   <complexType/>
   <attribute name="id" type="string"/>
</element>

<element name="BillingAddress" type="tns:BillingAddressType"/>

<element name="ShippingAddress" type="tns:ShippingAddressType"/>

  <complexType name="BillingAddressType"> 
     <sequence>
          <element name="street1" type="string"/>
          <element name="street2" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>

  <complexType name="ShippingAddressType"> 
     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>


</schema>

This schema can be used to generate XML documents where arbitrary elements can occur between the contents of ShippingAddress and BillingAddress. Even the empty element Info can have open content within it attributed to the appliesToEmpty attribute on the <defaultOpenContent> declaration.

Valid Instance for the above XSD:

<Order>
   <Info id="123">
        <HelloWorld/>
   </Info>
  <BillingAddress>
      <Welcome6>123</Welcome6>
      <street1>1, Courthouse Square</street1> 
      <street2>Apt 007</street2> 
      <boo2/> 
      <city>Hill Valley</city> 
      <state>CA</state> 
      <zip>91919</zip> 
      <foo3/> 
</BillingAddress>
  <ShippingAddress>
      <Welcome>123</Welcome>
      <street>1, Courthouse Square</street>  
      <boo/> 
      <city>Hill Valley</city> 
      <state>CA</state> 
      <zip>91919</zip> 
      <foo/> 
</ShippingAddress>
</Order>

<xsd:all> Group Changes

The "All" Model group was bundled with several restrictions when it was introduced in XML Schema 1.0.

1. The group disallowed multiple occurence elements to be a part of the content model.   The following is illegal in XML Schema 1.0

Example 15 <complexType name="FluxCapacitorType">
   <all>
       <element name="timeCalibrator" type="string" maxOccurs="unbounded"/>
       <element name="needsRecharge" type="boolean" minOccurs="3" maxOccurs="unbounded"/>
  </all>
</complexType>

Elements within <all> groups were supposed to have maxOccurs=1 and a minOccurs of 0 or 1.

i.e. elements occur in any order, but each element occurs exactly once, if present.

2. <all> group cannot be nested within another model group. What this means is that you cannot have an <all> nested within a <sequence> or a <choice> model group. Thus the following is illegal in 1.0.

Example 16 <complexType name="FluxCapacitorType">
  <choice>
       <element name="autoFunction" type="AutoFunctionType"/>
       <all>
            <element name="timeCalibrator" type="string" maxOccurs="unbounded"/>
            <element name="needsRecharge" type="boolean" minOccurs="3" maxOccurs="unbounded"/>
      </all>
   </choice>
</complexType>

3. You cannot extend a non-empty BaseType with an <all> content model. The following is illegal in 1.0

Example 17 <complexType name="BaseTimeTravelMachineType">
  <all>
        <element name="timeComputer" type="string"/>
        <element name="carrier" type="CarrierType"/>
  </all>
</complexType>

<complexType name="HighSpeedTimeTravelMachineType">
  <complexContent>
       <extension base="BaseTimeTravelMachineType">
            <all>
                   <element name="TravelerProfileReader" type="ProfileReaderType"/>
          </all>
       </extension>
   </complexContent>
</complexType>

4. You cannot have wildcards within <all> groups.  The following is illegal in 1.0.

Example 18 <complexType name="BaseTimeTravelMachineType">
  <all>
       <any/>
        <element name="timeComputer" type="string"/>
        <element name="carrier" type="CarrierType"/>
  </all>
</complexType>

XML Schema 1.1 has legalized all the above models.

Vendor Unique Extensions

Vendors can now define their own primitive datatypes and facets. For instance, it may provide support for a new primitive datatype called string, with it's own implementation defined facets. These datatypes will be in a vendor defined namespace in order to distinguish them from XSD's predefined datatypes. The treatment of  the vendor defined datatype depends on each vendor - and evidently, it may not be supported by a processor implemented by another vendor.

Example 19 <!--new custom integer datatype -->
<element name="age" type="xdk:integer"/>
<!--new custom 'era' facet -->
<simpleType name="TimeType">
     <extension base="xdk:oracleDateTime">
            <xdk:era="Andromedan"/>
      </extension>
</simpleType> Conditional Inclusion

This feature is primarily used to ensure that XML documents that may be defined down the future using a later version of XML Schema language [say 5.5] can be processed in compatibility mode by a XML Processor that supports a prior version of  XML Schema [starting from 1.1].  For instance, one of the element declarations in a user defined XML Schema may use a new construct that was introduced in XML Schema 5.5. If you need to process this XML Schema using an XML Schema 1.1 compliant processor, you have to have a feature that allows you to pre-process and selectively interpret the constructs that the 1.1 version processor understands.

For this purpose, XML Schema 1.1 introduces a new set of attributes in the Schema Versioning Namespace, as listed below.

The Schema Versioning Namespace has a URI - http://www.w3.org/2007/XMLSchema-versioning. Within this namespace URI are four attributes.

  1. vc:typeAvailable
  2. vc:typeUnavailable
  3. vc:facetAvailable
  4. vc:facetUnavailable
  5. vc:minVersion
  6. vc:maxVersion

Look at the 2 examples below. In the first example, the user intends to define an element named TimeMachine that can be interpreted by an XML Schema Processor that complies with version 1.6, as well as one that supports version 1.1.

Example 20 <!--The below declaration is accepted for pre-processing for XML Schema versions 1.1 [inclusive], but less than 1.6. [exclusive] -->
<element name="TimeMachine" vc:minVersion="1.1" vc:maxVersion="1.6">
   <complexType>
         <sequence>
           .....
</element>
<!--The below declaration is accepted for pre-processing for XML Schema versions 1.6 or later. It may have constructs that are not understood by 1.1 processors.
-->

<element name="TimeMachine" vc:minVersion="1.6">
      <complexPhasedDatatype>
          <prioritizedSequence>
                ...
</element>

In the second example, listed below, the user intends to signal the usage of a vendor defined datatype or facet through the first 4 schema versioning attributes listed above.

Example 21 <!--line 1 is for processors that implement the custom datatype, whereas line 2 is used by other processor implementations -->
<element name="EmmetBrownsLabHeight" vc:typeAvailable="xdk:feet" type="xdk:feet"/>
<element name="EmmetBrownsLabHeight" vc:typeUnavailable="xdk:feet" type="xsd:integer"/>

<!--declaration 1 is used by processor that implements the custom minLength facet. The latter declaration is the fallback used by other processors ->
<element name="ItemCode" vc:facetAvailable="xdk:minLength">
    <simpleType>
       <restriction base="string">
              <xdk:minLength value="1,2"/>
       </restriction>
    </simpleType>
</element>
<element name="ItemCode" vc:facetUnavailable="xdk:minLength" type="string"/>

3. Miscellaneous Enhancements Conditional Type Assignments

XML Schema 1.1 allows for dynamic type assignment based on XPath 2.0 boolean condition expressions.

See example below.

Example 22 <!--inline alternative type definitions -->
<element name="TimeTravel" type="TravelType">
      <alternative test="@direction='Future'">
          <complexType>
              <complexContent>
              <restriction base="TravelType"
                         ....
<!--        some past travel related elements go here -->
            </complexType>
       </alternative>
      <alternative test="@direction='Past'">
          <complexType>
              <complexContent>
              <restriction base="TravelType"
                         ....
   <!--        some future travel related elements go here -->
            </complexType>
       </alternative>
  </element>
                          OR
<!--Named alternative type definitions -->
<element name="TimeTravel" type="TravelType">
   <alternative test="@direction='Future' type="FutureTravelType"/>
   <alternative test="@direction='Past' type="PastTravelType"/>
</element>

Few points to note here.

  • You can only access attributes of the context node within the xpath expression. You cannot use child/descendant elements in the expression as you would have seen in the assert statements earlier in the article, nor anything on the ancestor axis. In the above example, direction is an attribute defined within  the complexType TravelType that is used to define the TimeTravel element.
  • The alternative types should be datatypes that are derived from the actual type defined on the element. In the above example, FutureTravelType and PastTravelType are derived from TravelType.
  • Just as you would model the namespaces in asserts, you could use the xpathDefaultNamespace attribute to qualify the xpath expression on the alternatives.

Inherited Attributes

Inheriting attributes allows access to attributes of ancestor elements within descendant elements. Though inheriting does not allow the attributes to actually appear on the descendant element in the XML instance, they can be effectively used within asserts and type alternatives for the descendant element. An attribute can be declared as inheritable by defining inheritable="true" on the attribute declaration, as illustrated below.

Example 23 <element name="TimeTravelType">
    <complexType>
         <sequence>
               <element name="GadgetType">
                    <alternative test="@mode='Past' type="PastGadgetType"/>
                    <alternative test="@mode='Future' type="FutureGadgetType"/>
              </element>
             <element name="dimension">
                 ....
                <assert test="@length > 200 and @mode='Past'"/>
                <assert test="@length <= 200 and @mode='Future'"/>
        </sequence>
        <attribute name="mode" inheritable="true"/>
    </complexType>
</element>

Note that defining an inheritable attribute does not prevent schema designer to define attributes with the same name on the descendant element datatypes. In that case, the local declaration prevails.

Default Attribute Group

Default attribute group defines a set of global attributes that can be accepted by all complexType definitions directly defined in the schema file. [not applicable to imported/included components]

Example 24 <schema targetNamespace="...."
                   defaultAttributes="myLocalAttrs"
                   ....>
     <element name="AllTimePieces">
               ...
     <element>
     <element name="MyTimePiece">
                   ...
      <element>
      <element name="HisMuchBetterTimePiece">
                ....
         </element>

        <attributeGroup name="myLocalAttrs">
             <attribute name="tpId" type="ID"/>
         </attributeGroup>
</schema>

<AllTimePieces tpId="NONE">
         <MyTimePiece tpId="0">
                        ....
          </MyTimePiece>
          <HisMuchBetterTimePiece tpId="1">
                        ...
           </HisMuchBetterTimePiece>
   </AllTimePieces> 

This eliminates the need for redundant reference to the attribute group within all complexType definitions that needed to share the same set of attributes.

Substitution Group Enhancements

SubstitutionGroups in XML Schema 1.0 allows elements to be substitutable for other elements. To be precise, it allows for replacing an element with another. XML Schema 1.1 enhances this functionality by allowing an element to be substitutable for one or more elements

Example 25 <!--SubstitutionGroups in XML Schema 1.0 -->
<element name="shipComment" substitutionGroup="po:Comment" type="ShipCommentType"/>
<element name="billComment" substitutionGroup="po:Comment" type="BillComentType"/>

<!--SubstitutionGroups in XML Schema 1.1 ->
<element name="Flute" substitutionGroup="po:MusicalInstrument po:WindInstrument" type="FluteType"/>
<element name="MusicalInstrument" type="po:MusicalInstrumentType"/>
<element name="WindInstrument" type="po:WindInstrumentType"/>

As seen in Example 25, the element Flute can be substituted for either the MusicalInstrument element, or the WindInstrument element, provided FluteType datatype is derived from MusicalInstrumentType and WindInstrumentType.

ID related changes

XML Schema 1.1 has revised ID semantics to allow elements to possess more than one xsd:ID attribute. XSD 1.0 had forbidden this usage for ensuring compatibility with DTDs. Schemas that intend to be compatible can choose to not use this feature.  It also allows ID attributes to have default and fixed values - again something that was forbidden in 1.0.

Example 26
<element name="Fruit">
   <complexType>
     <sequence>
          <element name="taste" type="f:TasteType"/>
           ...
      </sequence>
     <!--Illustrating more than one ID on an element -->
     <attribute name="fruitUID" type="ID"/>
     <attribute name="flavourUID" type="ID"/>
   <!--illustrating default value on an ID type attribute -->
    <attribute name="locationCode" type="ID" default="US-CA"/>
</element>

Redefine Replaced by Override

<redefine> construct in XML Schema 1.0 enabled users to extend or restrict element type declarations. What it did not allow was to create a new definition for the same element when redefining it.

Example 27 <!--Legal redefine in XML Schema 1.0 -->
<schema .....>
   <redefine schemaLocation="http://www.greatschemas.org/invoice.xsd">

    <complexType name="BillingAddressType">
<!--BillingAddressType is defined in the included schema above, and is being redefined -->
            <extension base="gsc:BillingAddressType">
                  <sequence>
                        <element name="BillingCode" type="string"/>
                  </sequence>
            </extension>
    </complexType>

    <!--
        Illegal redefine in XML Schema 1.0  where BillingAddressType has been defined in the included schema  above
       -->

      <complexType name="BillingAddressType">
                  <sequence>
                        <element name="TotallyDifferentBillingStuff" type="string"/>
                  </sequence>
            </extension>
    </complexType>
</redefine>

Moreover, XML Schema 1.0 had many conflicting and non-interoperable implementations for <redefine> that 1.1 decided to deprecate the <redefine> functionality and replace it with a richer <override> construct instead.

Example 28 <!--Legal override in XML Schema 1.1 showing extension of types-->
<schema .....>
   <override schemaLocation="http://www.greatschemas.org/invoice.xsd">

    <complexType name="BillingAddressType">
<!--BillingAddressType is defined in the included schema above, and is being redefined -->
            <extension base="gsc:BillingAddressType">
                  <sequence>
                        <element name="BillingCode" type="string"/>
                  </sequence>
            </extension>
    </complexType>

    <!--
        Legal override in XML Schema 1.0  where BillingAddressType has been defined in the included schema  above
       -->

      <complexType name="BillingAddressType">
                  <sequence>
                        <element name="TotallyDifferentBillingStuff" type="string"/>
                  </sequence>
            </extension>
    </complexType>
</override>

Note that <redefine>  has been deprecated, but not removed yet. The WG is still looking for feedback from users on this construct.  It MAY be removed from future versions of the specification.

Target Namespace attribute on local elements and attribute declarations

XML Schema 1.1 allows users to define targetNamespace on local element and attribute declarations. The namespace URI may be different from the targetNamespace defined on its ancestors or the schema element.

Example 29 <schema targetNamespace="http://xmlns.oracle.com/definitions" ..... elementFormDefault="qualifiied">
    <element name="Address">
           <complexType>
               <sequence>
                     <element name="street1" targetNamespace="www.alternatens.com/defns"/>
                       ....
               </sequence>
                <attribute name="id" targetNamespace="http://xmlns.groceries.com/defns"/>
             </complexType>
         </element>
</schema>

<schema targetNamespace="http://xmlns.oracle.com/definitions" ..... elementFormDefault="qualifiied">
    <import namespace="www.foreign.com/defns" schemaLocation="Alt_Objects.xsd"/>
    <element name="Address">
           <complexType>
            <complexContent>
              <extension base="ForeignAddressType">
               <sequence>
                     <element name="street1" targetNamespace="www.foreign.com/defns"/>
                       ....
               </sequence>
                <attribute name="id" targetNamespace="www.foreign.com/defns"/>
             </complexType>
         </element>
</schema>

4. New Datatypes and Facets

XML Schema 1.1 added several new core datatypes into its existing library.

xsd11_datatypes

1. The anyAtomicType datatype

This datatype has been newly introduced as the base type for all atomic datatypes in the Schema's datatype library. [i.e. string, float,boolean etc]. It extends from anySimpleType.

"In XML Schema, a simple type is either a list type, a union type, or an atomic type; however, these three kinds of simple type are not recognized explicitly in the type hierarchy. For XPath, it was necessary to distinguish atomic types from the other kinds of simple type, so xdt:anyAtomicType was invented to achieve this."

                - Michael Kay, SAXONICA

2. New Numeric Datatypes

A new datatype named precisionDecimal has been added to support IEEE-754 floating-point decimal datatypes. precisionDecimals carry a numeric value, an arithmetic precision and a sign. Apart from distinguishing between positive and negative zero, this datatype also holds NaN and positive/negative infinity in it's value space.

Example 30 <price>1200.04</price>
<price>INF</price>
<price>-INF</price>
<price>NaN</price>

3. Date/time Datatypes

The following new datatypes - dateTimestamp, dayTimeDuration and yearMonthDuration have been added to the library. dateTimestamp extends the existing dateTime datatype with a mandatory explicitTimezone facet. [the timezone portion was optional in the dateTime datatype.]

<element name="shipDate" type="dateTimeStamp"/>

<shipDate>2010-02-01T12:03:00-08:00</shipDate>
<shipDate>2010-02-01T12:03:00Z</shipDate>

Both new duration related datatypes extend from the existing duration datatype and does a simple restriction on its lexical space.

<!--2 years and 3 months yearMonthDuration -->
<sampleYearMonthDuration>P2Y3M</sampleYearMonthDuration>
<!--1 day and 6 hours dayTimeDuration-->
<sampleDayTimeDuration>P1D6H</sampleDayTimeDuration>

5. Next Steps

Several implementations are under development. This includes the upcoming versions of Xerces, and the SAXON processor. 

You can contribute to the specification by submitting your comments to the public comments mailing list for the standard - www-xml-schema-comments@w3.org. Here is the archive.

6. Credits

Roger Costello's Tutorial is one of the best you can grab to get to the next level of details on the specification. He has done a fabulous job in documenting all major features to fine levels of detail. You can find a link to his tutorial in the next section.

6. References

1. XML Schema 1.1 Part 1: Structures

2. XML Schema 1.1 Part 2: Datatypes

3. Roger Costello's XML Schema Tutorial

4. XML Schema 1.1, Part 1: An introduction to XML Schema 1.1 - IBM

5. XML Schema 1.1, Part 2: An introduction to XML Schema 1.1 - IBM

6. XML Schema 1.1, Part 3: An introduction to XML Schema 1.1 - IBM

Syntax Recognition for XML-Based Languages in Oracle JDeveloper

Thu, 2010-12-16 10:02

 

@Thanks Jeffrey Stephenson

If you are looking at using any one of the new XML Based languages, lets say a docbook xml, or xproc, or what not, you can make use of JDeveloper's syntax highlighting and completion insight feature to ease out those extra keystrokes.

All you need is a URL/local copy of the XML Schema for the language. Once you have, you can register it via Tools --> Preferences --> XML Schemas.
new_schema_language.JPG

 

Remember to provide a new extension name [Using a default .xml extension did not work for me.] I provided my own extension .dbk for my docbook files.

Once you save these settings, you can create new files that conform to the schema, and you get validation/completion insight/prompting for free.

 

validation_new_schema.JPG

 

 

Pages