Open Source vs. Open Standards
The Fallacy of Open SourceProponents of open source make a very compelling and seductive argument that goes something like this...
"All software has source code. The open source model grants every user access to that code, resulting in freedom. Freedom means choice and choice means power. You can see the code, you can change it and you can learn from it. New ideas and code travel the world in an instant. As a result, the open source model often builds higher quality, more secure, more easily integrated software. And it does it at a vastly accelerated pace and often at a lower cost. And when customers are unhappy with one vendor, they can choose another one without overhauling their entire infrastructure. No more technology lock-in. No more monopolies!"
However the reality can be vastly different. A real world implementation often requires many components drawn from different open source projects. Each independent project has its own release cycle and the onus is on the customer to coordinate, patch and update accordingly. Fixing and patching a security hole in one open source project is easy, but doing it for twenty projects over a period of months takes real skill and time. This is time you cannot afford. So your initiative that started out with little to no cost becomes a long term and expensive support burden. Ironically "reducing support costs" was probably the main reason for using open source in the first place.
The Power of Open StandardsSoftware based on open standards however, delivers the interoperability benefits of open source with the assurance of traditional software models. In many ways open standards are like open source. They begin when a collaboration of interested parties that results in a consensus on specifications for implementing common requirements. The use of open standards, improves the choices that help you to reduce risk, implement durable solutions, obtain flexibility and benefit from quality. Since multiple vendors can support open standards, you can spread the risk out among them instead of on one proprietary vendor, reducing overall risk related to dependency on and support for the technology. This also leads to increased durability of options, as open standards are able to last longer than limited open source solutions.
ActiveVOS - Open Standards-Based BPMAt ActiveEndpoints we're huge proponents of open standards. We've based our ActiveVOS BPMS on the open standards as defined by the leading standards bodies. We intimately collaborate with consortiums such as the Object Management Group (OMG) and the Organization for the Advancement of Structured Information Standards (OASIS) on specifications such as BPMN 2.0, BEPEL4People, WS-Human Task and many others. Our goal is to reduce your risk and provide you with the maximum flexibility.
Request an ActiveVOS trial today.
More about BPELBPEL is an XML language for describing business process behavior based on Web services. The BPEL notation includes flow control, variables, concurrent execution, input and output, transaction scoping/compensation and error handling.
A BPEL process describes a business process. Processes often invoke Web services to perform functional tasks. A process can be either abstract or executable. Abstract processes are similar to library APIs; they describe what the process can do and its inputs and outputs but do not describe how anything gets done. Abstract processes are useful for describing a business process to another party that wants to use the process. Executable processes do the "heavy lifting" -- they contain all of the execution steps that represent a cohesive unit of work.
A process consists of activities connected by links. (A process sometimes only contains one activity but that is usually a container for more activities.) The path taken through the activities and their links is determined by many things, including the values of variables and the evaluation of expressions.
The starting points are called start activities; their create Instance attributes are set to "yes." When a start activity is triggered, a new business process instance is created. From then on, the instance is identified by data called correlation sets. These data uniquely identify a process, but they may change over time. For example, the correlation set for a process may begin as a purchase order number retrieved from a customer order. Later, when an invoice is generated, the correlation set may be the invoice number.
BPEL is layered on top of other Web technologies such as WSDL 1.1, XML Schema 1.0, XPath 1.0 and WS Addressing. Leveraging the BPEL standard are the BPEL4People and WS-HumanTask specifications, which enable human interactions and a model of human interactions that are service-enabled.
A Web search for "BPEL" and "BPEL4People" will return a number of useful resources, including the specification document and numerous articles.
A BPEL XML file describes a business process, but it does not normally stand alone. BPEL processes may refer to Web services, which are described by WSDL files. They may refer to partners, described by partner files which in turn reference WSDL files that describe the partner link types.
WSDL files describe the structure of messages (data containers), operations (method calls), and port types (operations and input, output, and error messages). WSDL files also bind port types to particular protocols such as SOAP. Finally, these bindings are tied to specific URIs that offer the Web service.