Though Oracle Corporation (NASDAQ: ORCL) has taken a rather understated position towards service-oriented architecture (SOA) and business process management (BPM), its acquisition of Collaxa highlights that Oracle is factoring them into in its product strategy. Through Collaxa, Oracle will be able to provide new reporting features that will monitor the progress of business processes. It can now offer workflow capabilities, monitoring tools, and runtime support for business process execution language (BPEL). These developments should remedy any ambiguity in Oracle's SOA and BPM approaches. Additionally, Collaxa, could have a broader effect on a range of related Oracle products and may also give Oracle the opportunity to convert many more non-Oracle users.
Collaxa was founded in December 2000 by Edwin Khodabakchian, who was once part of the Netscape Communications server team and at AOL. Initially, the company's business model was similar to that pursued by WebLogic, before it was acquired by BEA. Its goal was to basically create the Java application server market. Likewise, Collaxa saw an opportunity to do something similar with its Web Services Orchestration Server (WSOS) product, (later renamed Collaxa BPEL Server and now called Oracle BPEL Process Manager). This product aimed to help Java developers tackle the integration of major projects by delivering an orchestration method of coordinating, managing, and monitoring Web services. Subsequently Collaxa set up close partnerships with all the major providers of J2EE application servers, such as BEA, IBM, Oracle, and Sun, all of which use WSOS for orchestrating. It also partnered with Computer Associates (CA) to provide its Unicenter infrastructure management platform with the support for the BPEL standard. However, now that Oracle has taken the bait and annexed the Collaxa product, only time will tell how these partnerships will continue.
Collaxa was one of the pioneers of Web services orchestration by using a two-step process to make Web services functional: publish first, and then orchestrate. In other words, integrate these published Web services and coordinate messages between them to create business processes.
Orchestration involves three main elements:
coordination, including asynchronous communications, parallel processing, event handling, business transaction protocol (BTP), clustering, and scalability;
management, including administration, cancellation and change management, exception and timeouts, and version control; and
activity monitoring, which includes business reporting, audit trailing, and non-repudiation.
However, the loosely coupled nature of Web services components can create complexities, such as the need for coordinating asynchronous messaging, which does not occur at predetermined or regular intervals. The term asynchronous is usually used to describe communications in which data can be transmitted intermittently rather than in a steady stream. For example, a telephone conversation is asynchronous because both parties can talk whenever they feel like. Otherwise, if communication were synchronous, each party would be required to wait a specified interval before speaking. The difficulty with asynchronous communications is that the receiver must have a way to distinguish between valid data and noise. In computer communications, this is usually accomplished through a special start bit and stop bit at the beginning and end of each piece of data. For this reason, asynchronous communication is sometimes called start-stop transmission.
Collaxa Uses BPEL
Collaxa managed the complexities of communication through its abstraction layer where its solution interacts with disparate execution systems through BPEL. It works by encapsulating the orchestration facilities needed to coordinate, manage, and monitor service-oriented business processes. Subsequently, developers are exposed to these facilities through a JSP-like component called ScenarioBean that is based on industry standards such as XML, SOAP, WSDL, Java Message Service, BTP, and ebXML (electronic business XML). In addition to the ScenarioBeans, which enabled Java developers to compose multiple Web services and user interactions, the Collaxa WSOS featured two other primary components: 1) the orchestration server, and the 2) Collaxa Web Service Orchestration Console for administering the services. Simply explained, Web services allow applications to easily exchange and reuse information. However, it is only when they are orchestrated (coordinated) into long-running business flows or processes that enterprises can realize their true value.
This is where BPEL comes into picture. BPEL, which is also known as BPEL4WS, is an XML-based language used to standardize business processes in a distributed or grid computing environment that enables separate businesses to interconnect their applications and share data. It provides a standard programming language that businesses can use to define how to combine Web services to accomplish tasks. The WS-coordination specification thereby describes how the individual Web services within that task will interact. Meanwhile, the WS-transaction standard will determine if all the transactions are either successfully completed or will fail as a group. In the Web services protocol stack, BPEL is a layer on top of WSDL, which it uses to specify actions that should take place in a business process. It describes the Web services provided by a business process.
Designed as a combination of proprietary specifications from IBM's Web Services Flow Language (WSFL) and Microsoft's XML business process language in BizTalk Server (XLANG), BPEL is platform-independent. It allows enterprises to keep internal business protocols separate from cross-enterprise protocols allowing internal processes to be changed without affecting the exchange of data from enterprise to enterprise. A BPEL document, for example, keeps track of all the business processes that are connected to a transaction and ensures that the processes are executed in the correct order through the automation of messages.
As a standards-based format that transfers processes between platforms while remaining platform-independent, BPEL seems to be becoming an important element in the taxonomy of Web services and BPM. Notably, BEA and SAP are also supporters. Collaxa, as a long time supporter of BPEL, boasts these two high-profile companies as users of its engine.
Customers can now use Oracle BPEL Process Manager to orchestrate processes deployed across either Java or Microsoft's .NET infrastructure. The product supports the latest standards such as BPEL 1.1 or XML 1.0, and Web services can make integrated business processes portable across platforms regardless of the underlying technology. Yet, while Oracle may rightfully be able to assert that its product is the only native BPEL server on the market, competitors BEA and webMethods have several, nominally non-native BPEL products on the market. These products enable import and export between BPEL and their own proprietary formats through partnerships like that with The Middleware Company. Despite its mighty backers, BPEL still remains one of a number of emergent standards in the general area of BPM. Others include business process modeling language (BPML) or XML processing description language (XPDL) and Web service choreography interface (WSCI), which is still backed by BEA, Intalio, SAP, and Sun.
Challenges
This brings us to Oracle's EAI and application server offering, which has only recently become as complete and as open as products like IBM WebSphere or SAP NetWeaver. Oracle nevertheless continues to incorporate changes around its mantra of standard, "vanilla-as-much-as-possible", all-encompassing enterprise systems. Although it is not yet giving up on being a single vendor solution, it has recently modified advice to users (see Oracle Makes a U-Turn at the 'All Things to All People' Exit) by providing its applications programming interfaces (APIs), data definition languages, and data to aid in integration.
Until recently, users would have to buy all three layers of Oracle products—Oracle Database, Oracle Application Server, and Oracle E-Business Suite—to leverage Oracle's vision of a complete collaborative business solution. Intriguingly, this meant that Oracle had to split some functionality across these three layers whereas other providers kept them strictly together at the application layer. Even with the existence of SAP NetWeaver and IBM WebSphere, only Oracle and Microsoft have all three platforms where functionality can be spread. No one else in the marketplace can do this. Thus many prospects may still not buy into the Oracle vision, fearing the technology lock-up and arm-twisting which can come from buying these three components. It is also apparent that Oracle intentionally dispersed capabilities across these tiers to compel customers who are serious about a complete solution to buy all three layers. As a result, it pushed the databases of Microsoft's SQLServer and IBM's DB2, and the application servers of IBM's WebSphere or BEA's WebLogic respectively, out of the picture. However nowadays, Oracle Application Server does not require the Oracle Database and vice versa, and Oracle E-Business Suite does not necessarily require Oracle Application Server, as more than two thirds of the Oracle E-Business Suite runs on Java and J2EE. This should assuage the lock-in fears of prospective users.
Yet, it is likely that Oracle will continue to focus on exposing processes within its applications and integrate its development tools to maximize the potential of Oracle BPEL Process Manager and further secure users. However, Oracle must also offer more advanced design and development tools that will automate the abridging of BPEL Process Manager, Oracle JDeveloper, and traditional models such as unified modeling language (UML). While Oracle's recent acquisitions should help with this effort, Oracle must do sizeable work to bring all these products together. The major weakness of the platform remains in its intricacy, but that is not attributable only to Oracle. Time will tell how Oracle BPEL Process Manager will fit with existing Oracle enterprise resource planning (ERP), customer relationship management (CRM) or supply chain management (SCM) applications. These are yet to be certified for Oracle Database 10g, albeit Oracle E-Business Suite 11i.10 is live on Oracle Application Server 10g.
For that reason, large enterprises will likely continue to look to other, possibly more complete, solutions. They may even go to the aforementioned BPM, SOA, or Web services vendors to create, manage, and orchestrate complex, high-volume processes that include people, structured data, unstructured content, and exceptions handling. Should Oracle squander the Collaxa opportunity to entice more non-Oracle shops, it will likely continue its hapless search for a "magic touch" that will differentiate its product offerings (see Stalled Oracle Fumbling For A Jump-Start Kit). Unfortunately for Oracle applications, though these attempts have been in right direction, they have largely been small steps, and many of them often revisited or revised. However, as of June 2004, over 22,600 customers use Oracle Application Server outside of Oracle E-Business Suite—excluding the 7,100 Oracle E-Business Suite customers using Oracle Application Server. These numbers show that at least Oracle Application Server reaches out beyond Oracle shops.
The idea to build out from core enterprise business process automation to other, more sophisticated outward-facing processes would be generally attractive if Oracle's ultimate "ulterior mode" was not to rip all the current enterprise systems running on its database and replace with Oracle's E-Business Suite. Although Oracle may be a compelling proposition to "green-field" sites (and how many of these are still out there?), many enterprises might remain skeptical or unimpressed when faced with the complexities of integrating with multiple legacy enterprise systems and the more recent third-party, best-of-breed extended-ERP applications.
SOURCE:http://www.technologyevaluation.com/research/articles/oracle-further-orchestrates-its-soa-forays-part-five-collaxa-acquisition-17841/
0 comments:
Post a Comment