Friday Jun 07, 2013

Oracle A-Team Chronicles Live!

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!

Sunday Sep 30, 2012

Adapters, SOA Suite and More @Openworld 2012

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.

Thursday May 03, 2012

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

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)

Thursday Mar 08, 2012

New Oracle SOA Support Blog

Check out the new Oracle SOA Suite Proactive Support Team blog at https://blogs.oracle.com/soaproactive/

Thursday Nov 17, 2011

Processing Binary Data in SOA Suite 11g

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.

Friday Sep 30, 2011

Nice Introduction to WLDF Watch/Notifications

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

Friday Sep 16, 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

Thursday Apr 28, 2011

Is Local Optimization kicking in your WS Binding?

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.

Wednesday Apr 06, 2011

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

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

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.

 

Wednesday Feb 16, 2011

Neighboring Siblings?

 

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.

 

Wednesday Jan 19, 2011

XML Schema 1.1 – What you need to know

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

Friday Dec 10, 2010

Detecting Process Shutdown/Startup Events through ActivationAgents

@10g - This post is motivated by one of my close friends and colleague - who wanted to proactively know when a BPEL process shuts down/re-activates. This typically happens when you have a BPEL Process that has an inbound polling adapter, when the adapter loses connectivity to the source system. Or whatever causes it.

One valuable suggestion came in from one of my colleagues - he suggested I write my own ActivationAgent to do the job. Well, it really worked.
Here is a sample ActivationAgent that you can use.
There are few methods you need to override from BaseActivationAgent, and you are on your way to receiving notifications/what not, whenever the shutdown/startup events occur.
In the example below, I am retrieving the emailAddress property [that is specified in your bpel.xml activationAgent section] and use that to send out an email notification on the activation agent initialization. You could choose to do different things. But bottomline is that you can use the below-mentioned API to access the very same properties that you specify in the bpel.xml.

package com.adapter.custom.activation;

import com.collaxa.cube.activation.BaseActivationAgent;
import com.collaxa.cube.engine.ICubeContext;

import com.oracle.bpel.client.BPELProcessId;

import java.util.Date;
import java.util.Properties;

public class LifecycleManagerActivationAgent extends BaseActivationAgent {

 

public BPELProcessId getBPELProcessId() {
return super.getBPELProcessId();

}

private void handleInit() throws Exception {

//Write initialization code here
System.err.println("Entered initialization code....");
//e.g.
String emailAddress = getActivationAgentDescriptor().getPropertyValue(emailAddress);
//send an email
sendEmail(emailAddress);

}

private void handleLoad() throws Exception {

//Write load code here
System.err.println("Entered load code....");

}

private void handleUnload() throws Exception {

//Write unload code here
System.err.println("Entered unload code....");

}

private void handleUninit() throws Exception {

//Write uninitialization code here
System.err.println("Entered uninitialization code....");

}


public void init(ICubeContext icubecontext)
throws Exception {
super.init(icubecontext);
System.err.println("Initializing LifecycleManager Activation Agent .....");
handleInit();

}

public void unload(ICubeContext icubecontext)
throws Exception {
super.unload(icubecontext);
System.err.println("Unloading LifecycleManager Activation Agent .....");
handleUnload();
}

public void uninit(ICubeContext icubecontext)
throws Exception{
super.uninit(icubecontext);
System.err.println("Uninitializing LifecycleManager Activation Agent .....");
handleUninit();
}

public String getName() {
return "Lifecyclemanageractivationagent";
}

public void onStateChanged(int i, ICubeContext iCubeContext) {
}

public void onLifeCycleChanged(int i, ICubeContext iCubeContext) {
}

public void onUndeployed(ICubeContext iCubeContext) {
}

public void onServerShutdown() {

}
}


Once you compile this code, generate a jar file and ensure you add it to the server startup classpath. The library is ready for use after the server restarts.

To use this activationAgent, add an additional activationAgent entry in the bpel.xml for the BPEL Process that you wish to monitor.
After you deploy the process, the ActivationAgent object will be called back whenever the events mentioned in the overridden methods are raised. [init(), load(), unload(), uninit()]. Subsequently, your custom code is executed.

Sample bpel.xml illustrating activationAgent definition and property definition.

<?xml version="1.0" encoding="UTF-8"?>
<BPELSuitcase timestamp="1291943469921" revision="1.0">
<BPELProcess wsdlPort="{http://xmlns.oracle.com/BPELTest}BPELTestPort" src="BPELTest.bpel" wsdlService="{http://xmlns.oracle.com/BPELTest}BPELTest" id="BPELTest">
<partnerLinkBindings>
<partnerLinkBinding name="client">
<property name="wsdlLocation">BPELTest.wsdl</property>
</partnerLinkBinding>
<partnerLinkBinding name="test">
<property name="wsdlLocation">test.wsdl</property>
</partnerLinkBinding>
</partnerLinkBindings>
<activationAgents>
<activationAgent className="oracle.tip.adapter.fw.agent.jca.JCAActivationAgent" partnerLink="test">
<property name="portType">Read_ptt</property>
</activationAgent>
<activationAgent className="com.oracle.bpel.activation.LifecycleManagerActivationAgent" partnerLink="test">
<property name="emailAddress">ramkumarmenon@toottoot.com</property>
</activationAgent>
</activationAgents>
</BPELProcess>
</BPELSuitcase>
em>

Monitoring Events in your BPEL Runtime - RSS Feeds?

@10g -

It had been a while since I'd tried something different. so here's what I did this week!
Whenever our Developers deployed processes to the BPEL runtime, or perhaps when a process gets turned off due to connectivity issues, or maybe someone retired a process, I needed to know.
So here's what I did.

Step 1: Downloaded Quartz libraries and went through the documentation to understand what it takes to schedule a recurring job.

Step 2: Cranked out two components using Oracle JDeveloper. [Within a new Web Project]

a) A simple Java Class named FeedUpdater that extends org.quartz.Job. All this class does is to connect to your BPEL Runtime [via opmn:ormi] and fetch all events that occured in the last "n" minutes.
events? - If it doesn't ring a bell - its right there on the BPEL Console. If you click on "Administration > Process Log" - what you see are events.
The API to retrieve the events is

//get the locator reference for the domain you are interested in.
Locator l = ....

//Predicate to retrieve events for last "n" minutes
WhereCondition wc = new WhereCondition(...)

//get all those events you needed.
BPELProcessEvent[] events = l.listProcessEvents(wc);

After you get all these events, write out these into an RSS Feed XML structure and stream it into a file that resides either in your Apache htdocs, or wherever it can be accessed via HTTP.
You can read all about RSS 2.0 here. At a high level, here is how it looks like.

<?xml version = '1.0' encoding = 'UTF-8'?>
<rss version="2.0">
  <channel>
    <title>Live Updates from the Development Environment</title>
    <link>http://soadev.myserver.com/feeds/</link>
    <description>Live Updates from the Development Environment</description>
    <lastBuildDate>Fri, 19 Nov 2010 01:03:00 PST</lastBuildDate>
    <language>en-us</language>
    <ttl>1</ttl>
    <item>
      <guid>1290213724692</guid>
      <title>Process compiled</title>
      <link>http://soadev.myserver.com/BPELConsole/mdm_product/administration.jsp?mode=processLog&amp;processName=&amp;dn=all&amp;eventType=all&amp;eventDate=600&amp;Filter=++Filter++</link>
      <pubDate>Fri Nov 19 00:00:37 PST 2010</pubDate>
      <description>SendPurchaseOrderRequestService: 3.0 Time : Fri Nov 19 00:00:37
                   PST 2010</description>
    </item>

  ......

</channel>

</rss>

For writing ut XML content, read through Oracle XML Parser APIs - [search around for oracle.xml.parser.v2]

b) Now that my "Job" was done, my job was half done. Next, I wrote up a simple Scheduler Servlet that schedules the above "Job" class to be executed ever "n" minutes. It is very straight forward.

Here is the primary section of the code.

        try {
        Scheduler sched = StdSchedulerFactory.getDefaultScheduler();

        //get n and make a trigger that executes every "n" seconds
        Trigger trigger = TriggerUtils.makeSecondlyTrigger(n);
        trigger.setName("feedTrigger" + System.currentTimeMillis());
        trigger.setGroup("feedGroup");       
        JobDetail job = new JobDetail("SOA_Feed" + System.currentTimeMillis(), "feedGroup", FeedUpdater.class);
        sched.scheduleJob(job,trigger);

        }catch(Exception ex) {
            ex.printStackTrace();
            throw new ServletException(ex.getMessage());
        }

Look up the Quartz API and documentation. It will make this look much simpler.

Now that both components were ready, I packaged the Application into a war file and deployed it onto my Application Server. When the servlet initialized, the "n" second schedule was set/initialized.

From then on, the servlet kept populating the RSS Feed file. I just ensured that my "Job" code keeps only 30 latest events within it, so that the feed file is small and under control. [a few kbs]

Next I opened up the feed xml on my browser - It requested a subscription - and Here I was - watching new deployments/life cycle events all popping up on my browser toolbar every 5 (actually n)  minutes!

rssfeed_image.JPG

Well, you could do it on a browser/reader of your choice - or perhaps read them like you read an email on your thunderbird!.

rssfeed_image_2.JPG


About

Principal Product Manager

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today