The purpose of life is not to win. The purpose of life is to grow and to share. When you come to look back on all that you have done in life, you will get more satisfaction from the pleasure you have brought into other people's lives than you will from the times that you outdid and defeated them.

I did what I was asked to do

“I did what I was asked to do”. There are quite a few among us who say this after getting poor appraisal ratings or after getting fired. This is not performance. These types of people are the ones who always run near and close to the boss to keep it going. But for organizations when it comes to retain the best, these are the ones who will be weeded out. There is nothing wrong in doing what was asked to do, to retain jobs, but ultimately the best performer is the one who is willing to go the extra mile.

Going for the extra mile is not working hard with extended hours. Employees are paid for 8hrs of work and not for slavery in the name of competitive world.

“A knife which does only one work of cutting needs to be sharpened frequently to work effectively”. Humans being multifaceted, need to work and rest for life not work and work for life. If promotions or growth can’t be fetched by working for 9 hrs a day, then there is some thing wrong in the way work is done or may be someone is not doing work at the right place. Doing that extra work for day and night and for everyday may not actually yield more than what can be collectively achieved by working peacefully everyday.

'either or' using XML Schema

By embedding choice in sequence, 'either or' type can be enforced in XML schema. In the below example, somethingType would allow either foo or bar. Since 'choice' is inside the sequence which can max occur twice, either or is enforced. So foo/bar can appear once or twice or they can both co-exist.

<xsd:complexType name="somethingType">
  <xsd:sequence minOccurs="1" maxOccurs="2">
    <xsd:choice>
      <xsd:element name="foo" type="xsd:string"/>
      <xsd:element name="bar" type="xsd:string"/>
    </xsd:choice>
  </xsd:sequence>
</xsd:complexType>

<?xml version="1.0" encoding="UTF-8"?>
<tns:EitherOr xmlns:tns="http://www.example.org/EitherOr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.example.org/EitherOr eitheror.xsd ">
  <foo>foo</foo>
  <bar>bar</bar>
</tns:EitherOr>

Who needs BPM?

BPM should be an organization wide initiative not a department specific or systems specific. This should be the real motivation for any company planning to invest in BPMS. All the business processes of the organization have to be discovered/implemented/migrated/automated to BPMS platform. This has to be the end state or at least should be an ideal state for the IT division of a company.

Workflow Systems:

Although BPM systems have its roots with Workflow systems, BPMS is definitely not an extension of a workflow system.
Workflow is no substitute for BPMS and BPM is rather looked at as systems-to-systems technology.
Also workflow is specific to a system/ collection of systems, but does not collectively represent a domain.

EAI/ESB:

With the advent of SOA, I feel the debate of whether we need to use ESB or existing EAI system becomes nullified.
SOA can be implemented either with EAI/ESB or even without these.
In my opinion BPM can be better sold with SOA rather than with ESB. ESB is perceived both as a product and as architecture. Let the customer decide whether he needs an upgrade from EAI to ESB with necessary cost justifications.

BPM complements SOA and vice versa.

XML Parsers

Five types of XML Parsers.

Event based push: SAX, XNI
Event based pull: StAX, XMLPull
Tree: DOM, JDOM , dom4j
Data Binding: JAXB, Castor
Query API: TrAX

Source: http://www.artima.com/intv/xmlapis2.html

Push APIs have a number of advantages. They are very fast. You don't need to read to the end of the document before you start working with the beginning of the document. They use very little memory, because the entire document isn't in memory at once. Instead, you just see sort of a peephole into the document, just the current thing you're looking at. Typically in a push API the work goes into building up some data structure and gradually filling it from the input document until there is enough information there to act on. If you're document is, for example, a collection of articles, a list of records, something for which there are clear chunks in the data and you can process each chunk individually, a push API works very well.

On the other hand, the whole callback interface observer design pattern can be less than ideal for some developers. This brings us to the second major style of XML API, and the newest style: a pull API. A pull API is still streaming, still very fast, still very memory efficient. But instead of the parser being in control, telling the client application when it has some new information, the client application is in control, and it asks the parser to give it the next piece of information when it wants it. But the basic advantages of a pull API are the same as with a push API, except maybe the pull API is little simpler. The implementations of the various pull APIs are not very mature yet. When you actually look at the ones out there—NekoPull, XMLPULL—they have a lot of idiosyncracies both with respect to Java and XML. That's mostly just a function of maturity. There's nothing fundamentally wrong with the idea of a pull API. They're not just fully baked yet. With a little time, in a year or two, I expect pull APIs will be a very popular style of XML parsing.

The third style of XML parsing, and perhaps the most obvious style to most programmers, is a tree-based API. In a tree-based API, an XML document is read by a parser, and the parser constructs an object model, typically around a tree with nodes for elements , attributes, comments, processing instructions, text, and so forth. The entire document is stored in memory. You use the methods of the object to query the document, to navigate the document, to change and modify the document, and so forth. There are more tree-based APIs than any other kind of API: DOM, JDOM, DOM4J, Sparta, ElectricXML, and my own XOM are all tree-based APIs.

The fourth style of API, which is also a fairly recent style, is a data-binding API. It is similar to tree APIs in that the entire document is parsed and an object model is built, but in a data binding API rather than having classes which represent XML concepts, like element and processing instructions, you have classes that represent the concepts the XML represents. So a book element might become a Book object. An employee element might become an Employee object. Typically, some form of schema is compiled to produce these classes automatically. Either a W3C XML schema language schema, a DTD, or a special purpose binding schema written just for that purpose in some special purpose schema language.

And then finally the fifth kind of API is what I would refer to as a query API. These would typically be things like TrAX for transforming with XSLT, or various APIs like Jaxen for searching with XPath. There are no real standards here, but there is some interesting work being done. Generally there the real focus, the real code, goes into the XPath or XSLT query, which we merely call from Java or some other language. It's like using SQL from inside a Java program using JDBC.