Monday Oct 21, 2013

Rapidly developing Oracle BPM application solutions with data source integration previously required significant Java and JDeveloper skills. Now using open source tools for open data development significantly reduces the coding needed. Key tasks can be performed with visual drag and drop designing combined with menu selections entry and automatic form generation directly from XSD schema definitions.

The architecture used is extremely lightweight, portable, open platform and scalable allowing integration with a variety of Oracle and non-Oracle data sources and systems.

Two videos available on YouTube walk through the process at both an introductory conceptual level and then a deep dive into the programming needed using JDeveloper, Oracle BPM composer and Oracle WLS (WebLogic Server) along with the CAM editor and Open-XDX open source tools.

Combining Oracle BPM with these open source tools provides a comprehensive simple and elegant solution set. Development times are slashed and rapid prototyping is enabled. Also existing data sources can be integrated using open data formats with either XML or JSON along with CRUD accessing via the Open-XDX Java component. The Open-XDX tool is a code-free approach where data mapping is configured as templates using visual drag and drop in the CAM Editor open source tool. XML or JSON is then automatically generated or processed (output or input) and appropriate SQL statements created to support the data accessing.

Also included is the ability to integrate with fillable PDF forms via the XML templates and the Java PDF form filling library. Again minimal Java coding is needed to associate the XML source content with the PDF named fields.

The Oracle BPM forms can be automatically generated from XSD schema definitions that are built from the data mapping templates. This dramatically simplifies development work as all the integration artifacts needed are created by the open source editor toolset.

The developer level video is designed as a tutorial with segments, hands-on demonstrations and reviews. This allows developers to learn the techniques and approaches used in incremental steps. The intended audience ranges from data analysts to developers and assumes only entry level Java skills and knowledge. Most actions are menu driven while Java coding is limited to simply configuring values and parameters along with performing builds and deployments from JDeveloper and Oracle WLS.

Additional existing Oracle online training resources can be referenced on Oracle BPM and WLS that cover other normal delivery aspects such as user management and application deployment.

Friday Apr 26, 2013

Background

Before there was either
XML or JSON there was EDI. JSON is very reminiscent of EDI, both
syntactically and conceptually, and that the claims made back then as
to why EDI would be sustained over XML. EDI was lightweight, human
readable, fast to process, compact and worked well with existing
systems exchanges and interfaces and had a dedicated following of
advocates. But EDI has significant flaws, it is brittle, difficult
to extend and has weak data typing, content validation and rendering
support. Also semantics in EDI are very limited and rely on external
referenced specifications with local human knowledge that is
notoriously difficult to align across implementations. Particularly
code lists value sets and cross field content validation rules were
especially problematic for EDI.

Moving past these
limitations standards setting organizations have adopted XML
technologies as the primary toolset in defining information exchange
specifications. Further more there is an extensive family of XML
technologies that support the complete ecosystem of semantics and
particularly the need for interoperability, security and common
meaning and rules. The diagram here illustrates that.

Figure 1 –
Information Exchange Conceptual Components

Referencing this
diagram, JSON is restricted to the Structure and Content
capabilities. XML on the other hand provides the ability to handle
rich exchanges where all the aspects shown can be managed. In
today's challenging commercial and government information sharing
world you must have the complete set of robust capabilities
available.

The JSON primary use case

JSON is designed for
web client interfaces to web services on the internet. Essentially
it is serialized Javascript objects which makes it a strong fit for
web browser native client side scripting that all the major web
browsers provide.

While XML does not fit
as well for that scenario there are many equivalent solutions using
different interfacing in the browser such as Adobe Flash, Microsoft
InfoPath, Oracle ADF, or open source solutions such as Netbeans
forms that are using XML. One advantage of these is the “write once” approach and
deploy anywhere to tablet, smart phone, or web browser.

XML and JSON Performance Analysis

The presumptions of how slow and resource-demanding "Fat” XML is compared to JSON’s lightweight payload do not hold up to a test. An experiment with 33 different documents and almost 1200 tests on the
most commonly used browsers and operating systems found the
performance for the total user experience, (transfer, parsing and
querying of a document), to be nearly identical for both XML and JSON
formats.

Clearly this shows that you should perform experiments, test your own data and code with your own users and devices to determine real results. What "seems obvious" is not always true.

Selection of useful links of peoples opinions and
thoughts

We present here a
selection of “what does the internet think?” resources to show
the context to the use of JSON and insights into processing and
handling content in a web browser delivery context.

"We are conducting an experiment in XML and JSON performance in
browsers and would appreciate anyone with a couple minutes to spare
to visit this website and push one button.http://speedtest.xmlsh.org
(the results will be analysed and published - at this coming
Balisage 2013)

Summary and
Conclusions

Number one thing to
notice here is you are reading this document and it is being
delivered and rendered to your computer screen using XML, RSS and xhtml and not
JSON.

Back in the day when
XML was brand new, Bill Gates held a press conference to announce
that Microsoft would be adopting
XML wholesale for use across its products and
Windows operating system. This tells us that XML is ubiquitous and
extensible (that is in its name). There is now a huge number of XML
based standards in a family of solutions that support all aspects of
the needs of information exchange. In today's challenging world you
cannot just discount those as unnecessary.

When you look at
information exchanges the diagram provided in the introduction
section above it shows the complete ecosystem of components that you
need for effective consistent, trusted, predictable, reusable and
extensible information flows. Also we can see that JSON is missing
key delivery control and semantic pieces and thus JSON has a very
limited mission profile. Within that profile when fit-to-purpose it
can be effective, but as a general solution it does not meet all the
extended requirements.

Clearly JSON has its
niche following and will continue to serve that for its primary use
case of web based point client-server information exchanges. That is
not necessarily a bad thing. Having lightweight alternative
solutions is perfectly acceptable for a lot of content delivery
circumstances.

People should not
confuse business operational convenience with overall applicability -
e.g. Twitter and FourSquare dropping XML and relying solely on JSON.
Both of these services use simplistic formats totally under their
sole edict that are unlikely to change in the future. Also there are
competitive reasons, JSON actually can make it harder with its
limited semantics for competitive sites to harvest then analyze and
reuse and republish their content.

As a technology XML
continues to improve and its use is being better optimized and
refined, with tooling support that is narrowing the gap in areas
where JSON claims to have the technical edge today. Specifically we
can point to Oracle's work on Open Data APIs using Open-XDX that
supports both XML and JSON outputs. And the CAM
templates approach with NIEM that comes with
that and enables content providers to rapidly build working web
services and user form interfaces from SQL data stores.

In short we can expect
to see both XML and JSON to continue to fulfill information delivery
needs going forward but the differentiations are likely to blur.
Neither one is going to displace the other in core areas of use.
Providing the capability to use and support both is not a
significant burden and thus meets personal preferences and local
project nuances.

To get a sense for all
this as a brief real time interactive example you can try these two
live demonstration service points.

This one is using XML
when you
click here. And this one is doing the same
thing (its actually the same Open-XDX service component) but returns
JSON instead when you
click here.

Addendum

JSON is much simpler than XML.
JSON has a much smaller grammar and maps more directly onto the
data structures.

Simplicity
is deceptive. XML can easily be used as simply as JSON
syntactically. But simplicity comes at the price of ignoring many
common more robust information sharing needs in an extended
network – rather than just point-to-point.

The mapping referenced here is for
objects within a JavaScript environment only. Outside of that
context this is not so. All major programming environments have
robust XML support.

Extensibility

XML is extensible because it is a
mark-up language

JSON is not extensible because it
does not need to be. JSON is not a document markup language, so it
is not necessary to define new tags or attributes to represent
data in it.

This is a naïve view. Things
change constantly with new information sharing needs.
Particularly as more participants are added to exchanges and
standards evolve. Only in limited cases such as Twitter can we
see set formats.

Interoperability

XML is an interoperability
standard.

JSON has the same interoperability
potential as XML.

JSON clearly has significant
limitations and gaps with regard to information semantics and
reuse.

Openness

XML is an open standard

JSON is at least as open as XML,
perhaps more so because it is not in the center of
corporate/political standardization struggles.

This is a highly subjective
statement. XML has proven to be universally adopted and
implemented not just in software but firmware devices and
communications systems. Notice the JSON work is not immune from
manipulation as anything else as happened with JavaScript itself.

Human Readable

XML is human readable

JSON is much easier for human to
read than XML. It is easier to write, too. It is also easier for
machines to read and write.

Again this is an entirely
subjective statement. Markup is markup there is no “easier”
here. Machines have no notion of “easier”. The notion of
“easier to read” and presumably comprehend the meaning of is
notoriously hard to define.

Exchange Formats

XML can be used as an exchange
format to enable users to move their data between similar
applications

The same is true for JSON

Agreed.

However XML also has security and
other capabilities that are absent from JSON.

Structure

XML provides a structure to data
so that it is richer in information

The same is true for JSON.

However XML can provide deeper
structuring than JSON supports. It can also handle more extended
content types.

Processed

XML is easily processed because
the structure of the data is simple and standard.

JSON is processed more easily
because its structure is simpler.

Again this is entirely subjective.
See the link provided in the links section on machine timings
testing.

Code Re-invention

There is a wide range of reusable
software available to programmers to handle XML so they don't have
to re-invent code

JSON, being a simpler notation,
needs much less specialized software

JSON is mainly available in
JavaScript and not in a wide range of programming environments.
Further it is not the simplicity of the syntax, it is the
drastically reduced capabilities. Hence JSON only provides very
limited functionality.

XML separates the presentation of
data from the structure of that data.

XML requires translating the
structure of the data into a document structure.

JSON structures are based on
arrays and records.

This is only in the context of
the data within a web browser memory. Whereas XML is the native
format that underpins the spreadsheets, databases and array stores
that JSON content must ultimately be persisted to and from!

A common exchange format

XML is a better document exchange
format. Use the right tool for the right job.

JSON is a better data exchange
format.

Again this is entirely subjective
and no metrics are being given here. What defines “better”?
Clearly JSON is significantly less capable and restricted in it
use cases. Therefore “your mileage may vary in actual use”
would be an appropriate caution here when trying to measure what
is “better” where and how.

Data Views

XML
displays many views of one data

JSON does not provide any display
capabilities because it is not a document markup language.

XML has broader applicability.
Therefore you can write once, use everywhere. While JSON can
expect to be changed into XML for such extended uses.

Self-Describing Data

This is a key XML design
objective.

XML and JSON have this in common.

However XML has richer semantics
available than JSON.

Complete
integration of all traditional databases and formats

(Statements about XML are
sometimes given to a bit of hyperbole.) XML documents can contain
any imaginable data type - from classical data like text and
numbers, or multimedia objects such as sounds, to active formats
like Java applets or ActiveX components.

JSON does not have a <[CDATA[]]>
feature, so it is not well suited to act as a carrier of sounds or
images or other large binary payloads. JSON is optimized for data.

Visual content is data! Ask the
FBI analyzing the recent Boston attacks. One could also say that
JSON is limited to only simple basic data content and lacks
extended validation such as code values, date and number
formatting.

Internationalization

XML and JSON both use Unicode.

XML and JSON both use Unicode.

However JSON has limitations in
its use of encoding and exchanges.

Open
and extensible

XML’s one-of-a-kind open
structure allows you to add other state-of-the-art elements when
needed. They can always adapt your system to embrace
industry-specific vocabulary.

Those vocabularies can be
automatically converted to JSON, making migration from XML to JSON
very straightforward.

Exactly, if you have XML it is
trivial to generate JSON. The reverse is not the case however.

Readability

XML is easily readable by both
humans and machines

JSON is easier to read for both
humans and machines

This is an entirely subjective
statement. The better answer is that well written XML and JSON are
equivalent for human and machine handling.

Object-Oriented

XML is document-oriented.

JSON is data-oriented. JSON can be
mapped more easily to object-oriented systems.

The reverse is an issue however,
objects do not necessarily map easily to documents. Plus not all
content is objects; it actually constrains the use model. XML on
the other hand is well equipped for use as object-oriented content
as well as documents.

Adoptation

XML
is being widely adopted by the computer industry

JSON is just beginning to become
known. Its simplicity and the ease of converting XML to JSON make
JSON ultimately more adoptable.

The use of JSON is limited to web
client-server scenarios. Within that domain it is popular.
Outside of that domain XML completely dominates.

Thursday Oct 25, 2012

Learn how to build a working XML query/response system with SQL database accessing and XML components from example NIEM schema and dictionary.

Software development practitioners, business analysts and managers will find the materials accessible and
valuable in showing the decision making processes that go into
constructing a working XML exchange.

The 22 minute video available online shows how to build a
fully working ULEXS-SR exchange using a Vehicle license search example. Also included are aspects of NIEM training for assembling an IEPD schema with data models.

Materials
are focused on practical implementers, after viewing the instruction
material you can use the open source tools and apply to your own
SQL to XML use cases and information exchange projects.

All the SQL and XML code, editor tools, dictionary and instructions that accompany the
tutorial video are also available for download so you can try
everything yourself.