Upthrust

What is a business process? A series of steps that need to be performed in order to provide goods or services. Processes that used to be performed by humans are becoming increasingly automated by enterprise IT, allowing them to be performed more quickly and reliably and at much greater scale. But there can be unintended consequences – reverberation of failures, lack of accountability, an inability to handle situations outside the norm.

So why are business processes challenging to get right? Getting it right often means striking a good balance between automation and using the wisdom and flexibility of the human mind. But the technologies and systems for automating interactions which include humans differs substantially from automating interactions among software applications. This gulf has been difficult to bridge. Until now.

The recent introduction of two new standards in this space – BPEL4People and WS-Human Task – enables organizations to extend automated systems smoothly to include human interaction. WSO2 supports these new capabilities in the latest release of the WSO2 Business Process Server.

Your presenter, Milinda Pathirage, will cover the following topics:

• Scenarios highlighting business process involving humans
• Insights into BPEL4People and WS-Human Tasks
• Overview of the WSO2 Business Process Server
• Review of the new human-interaction features of the latest version of the WSO2 BPS

Who should attend:

• Architects and developers expanding their toolkit to include business processes
• Business process analysts
• Consultants and analysts specializing in SOA

Register here.

Each and every WSO2 Carbon 3.0.0 based product contains a “Registry” which we used to store data. There three main partitions of this registry space which used to store different kind of data namely, Local Data Repository, Configuration Registry and Governance Registry. This registry space partitions are there to allow share resources and configuration replication.

Local Data Repository

Contains system configuration as well as runtime data that is local to a single instance of a product. This partition of the registry space is not for sharing among multiple servers.

Configuration Registry

This is the most widely used partition and contains product specific configurations intended to be shared across multiple instances of the same product(for example, a cluster of ESB instances sharing set of proxy service configurations).

Governance Registry

Contains data and configuration shared across the platform. The WSO2 Governance Registry makes use of this partition of the registry space to store services and related metadata such as WSDLs, schemas, policies and endpoints. The governance registry partition has been designed in a way that it can be made use of by multiple instances of various Carbon based products.

You need to be careful when using these separate partitions when designing you solutions and “Sharing Registry space across Multiple Product Instances” article describes how you can leverage the registry partitions to successfully implement highly scalable SOA based solutions using WSO2 Carbon based products.

• Function names matter: we’ve known this for a long time, but now we know that we scan function names first. A good name, and you don’t need to focus on the implementation all that much.
• Variable names matter: again, nothing new. Notice, though, how the eye goes back to the variable definition and assignments. We constantly look for reminders of the state of the variable.
• Loops are the source of all evil: well, that’s not entirely true, but they are worse than all other statements. Notice how figuring out the loop is the most time consuming bit of the code. It’s where most pitfalls are (Oh, the index should be smaller OR EQUAL. Right. I forgot). Commenting can help some, but just keeping the conditions simple and readable is key. Break complexity down around the loop.
• Short code is easier to process, so get your refactoring tools out, everybody, it’s time to split these functions.

Read More….

In this presentation, Joshua Bloch and  William Pugh describes eight short Java programs with curious behavior. Things discussed in this presentation will help you a lot, if you are a Java developer.

Following is the list of problems and summary of things you can learn from studying those problems.

1. The Joy Of Sets

What is the out put of following program.

Moral of the above problem:

• Collection<E>.remove takes Object, not E
• Integral arithmetic always results in int or long
• Avoid mixing types
• Avoid short; prefer int and long

2. More Joy of Sets

Out put of the above program will depends on the whether you are connected to internet or not. This happens because URL’s equals and hashCode are broken.

Things we can learn from above problem:

• Do not use URL as a Set element or Map key
  • equals and hashCode aren’t well defined
  • They do not obey their general contracts
• Use URI instead of URL
  • Make URL from URI as neccessary
• equals should not depends on the environment

3. Racy Little Number

How often does the following test pass.

Moral of the problem:

• JUnit does not support concurrency
• You must provide your own way of handling concurrency
  • If you don’t you will get a false sense of security

4. Elvis Lives Again

What does following program print?

Moral of the problem:

• Wrapped primitives aren’t primitives
  • Prefer primitives to wrapped primitives
• Auto-unboxing can occur when you leas expect it
  • It can cause NullPointerException
• Never use Boolean as a three-valued return type
  • Almost guarantees NullPointerException
• Watch out for circularities in class initialization
  • Construct instance at end of class initialization

5. Mind The Gap

What does following program prints?

Moral of the problem:

• The skip method is hard to use and error prone.
• Use your skipFully(you will learn about it during the presentation) instead of skip
• More generally, if an API is broken, wrap it
• For API designers
  • Don’t violate the principle of last astonishment
  • Make is easy to do simple things

Tom Wujec presents his research into the “marshmallow problem” — a simple team-building exercise that involves dry spaghetti, one yard of tape and a marshmallow. Who can build the tallest tower with these ingredients? And why does a surprising group always beat the average?

Latest release(version 2.0.0) of WSO2 BPS, includes a fix for supporting custom XPath functions based on Saxon. There was a class loading issue in the previous releases of WSO2 BPS, which breaks the custom XPath function support.

Now you can write your own custom XPath extension functions as described in Saxon’s extensibility documentation, deploy them on WSO2 BPS and use them in you process definitions.

To deploy your XPath extensions in WSO2 BPS, you need to copy them into the BPS_HOME/repository/components/lib directory.

When writing XPath extension functions, there are some special cases. For example, if you want to pass a BPEL variable(WSDL Message or XSD Element type) into your extension functions, in simplest way, you need to use net.sf.saxon.om.NodeInfo as the parameter type. According to Saxon documentations DOM Node as the input parameter also should work when you want to get a XML element as the input. but I couldn’t get it to work when I am doing tests. And if you need to access XPath processing context, you need to have XPathContext as the first parameter to your function. When you want to return XML elements from your extension functions, you can use return type as org.w3c.dom.Node.

When returning XML elements, please make sure to create them using DOM AI tried to create DOM from a string like following. But failed when evaluating XPath on the return value as well as converting that DOM to AXIOM OM when sending response back to the BPEL process caller at the integration layer.

Here is the final sample extension source.

And here is how you can use that extension inside BPEL process definition. In this sample, I am creating the response XML using this custom XPath function.

If you have any questions on custom XPath function in WSO2 BPS, please feel free to put comment on this post. You can use extension written following above guidelines in Apache ODE also. In Apache ODE case you need to copy extension JAR into Apache ODE web application’s lib directory or relevant place in your JBI based Apache ODE deployment.

jQuery is one of the popular JavaScript frameworks out there and it simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development.

To get the best out of any framework or API used for developing software, developers need to understand fundamentals of that framework and need to get the know how of basic building blocks of those frameworks. This is same for jQuery as well.

Open sourced training materials and the book from Rebecca Murphey will help you a lot to get the jQuery fundamentals right.

boston.com has published nice set of pictures taken during first week. Here are some pictures from the boston.com article.

South Africa's midfielder Siphiwe Tshabalala

Argentina's Jonas Gutierrez

WSO2 released the latest version of it’s BPEL based process server, last Saturday(12th June 2010). WSO2 added WS-Human Task based BPEL4People support to this version of WSO2 BPS. Currently BPEL4People support is at it’s early stage and upcoming releases will provide users with comprehensive human and process integration through improved human task engine. New features in this release includes,

• BPEL4People and WS-HumanTask Support(Experimental)
• Instance cleanup scheduled task for production deployments
• Component manager to install and uninstall features (provisioning support)
• External service invocation via JMS
• XPath extension support

in addition to various bug fixes to underline BPEL engine(Apache ODE). You can download new release from Oxygen Tank’s download page.

Last year’s WSO2 SOA Summer School helped more than 1000 enterprise IT architects and developers to become more familiar with SOA concepts, technologies, and best practices—expanding the expertise they bring to their current or prospective employers. This year we are offering a completely new weekly series of sessions ranging from SOA to Cloud. Summer School 2010 runs for two months starting 10^th June and ending on 29^th July. Join us this Summer to learn the ultimate tips, techniques and practical advice on SOA and Cloud.

• Understanding the Cloud Landscape
• Understanding Enterprise Middleware – Build an Agile Architecture
• SOA Essentials – Getting your ESB and Governance right
• Business-facing SOA
• Extending SOA with CEP, Eventing and Rules
• Security in SOA
• Under the WSO2 Hood
• The Best of the Summer