|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 16
Messages: 16
Messages: 16
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
BEA and IBM submit joint white paper on BPELJ
BEA and IBM have released a white paper on their proposal for BPELJ. BPELJ is a fusion of BPEL and Java that allows these two programming languages to be used together to build complete business process applications. By enabling BPEL and Java to work together, BPELJ allows each language to do what it does best.
IntroductionThe Web Services Business Process Execution Language (BPEL) is a programming language for specifying business processes that involve Web services. BPEL is especially good at supporting long-running conversations with business partners. Even before the standard is formally released it is becoming clear that BPEL will be the most widely adopted standard for business processes involving Web services. BPEL is geared towards 'programming in the large', which supports the logic of business processes. These business processes are self-contained applications that use Web services as activities that implement business functions. BPEL does not try to be a general-purpose programming language. Instead, it is assumed that BPEL will be combined with other languages, which are used to implement business functions ('programming in the small').
"This white paper proposes a combination of BPEL with Java, named BPELJ, that allows these two programming languages to be used together to build complete business process applications. By enabling BPEL and Java to work together, BPELJ allows each language to do what it does best." The white paper is here:
BPELJ: BPEL for Java technology
There’s also an interesting opinion piece on this over at the register:
IBM moots BPEL-Java fusion
|
|
|
Message #115102
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deja Vu
Reading the white paper, I get a feeling that I have seen the concepts before.
A company called Intalio already provide similar features and has a nice GUI tool ('Designer') to specify your BEPL, transactions, mappings, functions etc. They have their own app server that then runs your BEPL for you too.
I don't work for Intalio, but had to use their tools on a project for a client last year and the Designer product was a little flakey at the start of the project, but was vastly improved by the end. I guess by now it will be bug free and working well. The server component worked really well throughout.
Definitely worth a look if you need the aforementioned features today. (And I really dont work for them!)
|
|
|
Message #115108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A step in the right direction, may be not
This proposal is a step in the right direction but it suffers from a few flaws.
A step in the right direction because there is a high need to be able fragments of procedural code within a BPEL process (((for those who are not familiar with BPEL, BPEL is a specification submit by Microsoft, IBM and bunch of others to OASIS for addressing the need for Web service composition/Workflow coordination in a Web services world. BPEL is a language that allows a developer to define a flow for sending and receiving messages across a network of services))): As you implement a flow, you might need to perform small computation, call a session bean, validate some piece of data. As suggested by the proposal, those requirements are better addresses by inline fragment of Java codes as a step in the process rather than having to wrap the fragment as a full blown external service.
But this proposal has also a lot of flaws and seem immature. As context, Collaxa worked about 3 1/2 years on a concept called ScenarioBean that tried to bridge the gap between BPEL and Java. ScenarioBeans suffered from a lot of the same shortcomings so nobody should get defensive about this.
Shortcoming #1: What ever solution the community develops for procedural embedding within BPEL should be language neutral. As a developer, I should be allowed to embed within a BPEL process a code fragment in Java, JavaScript, C#, etc using the same concepts and syntax.
Shortcoming #2: The essence of BPEL (and its power) is that data is modeled as document and messages and XML Schema provides metadata about the structure of those documents. This unification is very powerful because it allows for better tooling. Introduction of serializable Java object into the BPEL type system is a big step backward as it allows people to mix and match documents with object and does not constraint developers to clearly separate orchestration logic and other type of business logic. This will open the door to a lot of spaghetti code.
Shortcoming #3: JAXB mapping. XML/Java mapping is a though problem. It works well for simple XML documents (mostly the ones that vendors ship as demo with their products) but quickly hit the wall when you try to develop any real world application that usually entails more sophisticated data structure (STAR BODs, etc.). This is not a shortcomings of Java. It is simply related to the fact that an object tree is not a good representation of a document structure. This is why XML was created, this is why languages like XPATH, XQuery exist. Given that this is a tough problem, we should assume that things are going to evolve in the coming years. BPEL procedural embedding should not be dependent on this moving target.
Shortcoming #4: JAXB mapping. Another very common use case that is not well addressed with this proposal is that BPEL process often deal with large XML documents. In that context, streaming is an important aspect of the solution. Representing XML document as Java Objects again falls short at addressing this requirement and will entail significant performance problems.
Shortcoming #5: Java Annotation. BPEL is complex enough. Embedding BPEL into a Java comment just so that a BPEL process can call a functions seems an awfully complex solution to a very simple problem. It would so much simpler to encapsulate the Java code in a stateless session bean and call out that session bean when needed...or even a simple Java static class.
Shortcoming #6: Procedural invocation. This again mixes the boundary between orchestration logic and simple business logic fragment! This is just so inconsistent!
If I had to summarize, the biggest shortcoming of this proposal is that it blur the boundaries between orchestration logic and traditional procedural language/business logic. This is BAD because it will result in a lot of spaghetti code and makes BPEL more complex than it needs to be while damaging some of the key concepts, patterns and value proposition of BPEL (every thing is a document (data decoupling), everything is a service (interaction decoupling), orchestration logic is declarative (visualization and adaptability, bridging the bap between business analyst and developer).
A better solution would be to ....address this requirement by adding a single activity (<exec>code fragment</exec> and NOT mess around with the other parts of the BPEL language and ...make sure that the same activity can be used to embed a fragment of C# code or Java code ((<execute language="C#|Java">code fragment</execute>) so that BPEL keeps its portability.
|
|
|
Message #115110
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Deja Vu
If you want to design processes today that are deployed as J2EE components, you can use WebLogic Workshop. In the current version (8.1), Workshop uses the JPD file format, which is different from BPELJ, but the next major version will support BPELJ and will be backwards compatible and allow you to migrate your work.
Jesper
|
|
|
Message #115128
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Problem with embedded Java in XML
Good day,
I am not an XML expert but I thought that if data could be recognized as markup, it needed to be put into a CDATA section? For Java, this is definately true when you look at the JDK 1.5 support for generics, which denotes the type of a container with <...> such as
ArrayList<Integer> list = new ArrayList<Integer>();
list.add(0, new Integer(42));
int total = list.get(0).intValue();
Now, in Java, the following is also valid syntax:
int[] a = {1,2};
int[] b = {3,4};
if (b[a[0]]>4)
///do stuff
The "]]>" denotes the end of a CDATA section (assuming one was started). This means that the BPELJ document will either fail validation because the examples do not show it wrapping the code in CDATA and the code could contain markup syntax or it could fail validation if CDATA is used and the above example appears in the character data. Remember that the spec states that a '>' "need not (and cannot) be escaped using "<""
Any thoughts on this?
Sean
|
|
|
Message #115129
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Problem with embedded Java in XML
Oops...answered my own question. The '>' must be escaped if it appears in the string "]]>" and that is not the end of the CDATA.
I will assume that in the final spec the character data fields will be XML compliant.
|
|
|
Message #115137
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BPML
Vince,
Perhaps you are thinking of Business Process Modeling Language (BPML), a standard proposed by the Business Process Management Initiative, of which Intalio is a member.
Regards,
Jim Greer
|
|
|
Message #115184
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BPML is DOA, long live BPEL
Unfortunately for Intalio, BPML became DOA as soon as IBM and Microsoft published the BPEL specification and consequently submitted it to OASIS for standardization.
Doron.
Organic BPEL
|
|
|
Message #115195
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A step in the right direction, may be not
Embedding BPEL into a Java comment just so that a BPEL process can call a functions seems an awfully complex solution to a very simple problem. Agreed. I wonder if a Groovy binding would be easier to use. Groovy could help in two ways: its DOM syntax for easy document loading, and its command interpreter for defining logic on demand.It would so much simpler to encapsulate the Java code in a stateless session bean and call out that session bean when needed...or even a simple Java static class I wonder which is easier to use, BPELJ or IBM's BPWS4J? The BPWS4J container sounds very appealing:
"The BPWS4J engine supports the invocation, from within the process, of Web services that have a SOAP interface, that are EJBs, or that are normal Java classes." http://www.alphaworks.ibm.com/tech/bpws4j
|
|
|
Message #115291
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BPML/BEPL - whats in a name?
Vince,Perhaps you are thinking of Business Process Modeling Language (BPML), a standard proposed by the Business Process Management Initiative, of which Intalio is a member.Regards,Jim Greer Hi Jim,
well BEPL and BPML are very, very similar. In fact, I belive that BEPL heavily 'borrowed' from BPML as Microsoft and 'add your own other big company' like to do ;-).
I also know that Intalio were converting their products to run with BEPL, and that most of the changes were simply in name only.
Vince.
|
|
|
Message #115343
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BEA and IBM submit joint white paper on BPELJ
Has anyone got any experience with JBPM (www.jbpm.org), or XFlow, etc?
|
|
|
Message #115504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Language independence can be achieved through tools
Once you have it in Java, you can get it in C++ or .NET by using third party tools. Personally, I prefer our own (JunC++ion and JuggerNET), but there are plenty of competing products on the market that make Java a great starting point for connectivity.
|
|
|
Message #115591
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A step in the right direction, may be not
A better solution would be to ....address this requirement by adding a single activity (<exec>code fragment</exec> and NOT mess around with the other parts of the BPEL language and ...make sure that the same activity can be used to embed a fragment of C# code or Java code ((<execute language="C#|Java">code fragment</execute>) so that BPEL keeps its portability. That's precisely what the BPEL activity in Fiorano latest ESB 3.5 version
can do!
Thanks,
Amit Gupta
Fiorano Software Inc.
|
|
|
Message #115605
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BEA and IBM submit joint white paper on BPELJ
There seem to be two camps involved – those who see this as something necessary to ease the burden on the poor Java programmer. For them, something like BPELJ sounds much easier to deal with than having to jump through hoops to work with BPEL. Here, ‘loose coupling’ is a pain in the butt. BPELJ lets them insert a ‘work around’ to get by a whole raft of difficult situations.
At the other end of the scale are those folks who (like me) are looking at BPEL as an execution language for ‘Business Processes’ (and there are still many issues there). Here, the engine can read the definition and execute. The semantics of the process need to be separated out from detailed programming of functional calls. If we can do that then there is a chance to close the gap between business users (who dream up new ways of working) and the systems that are used to support their operations. With the right tools, they can envision a process and then ‘make it so’, without resorting to an army of programmers – modern BPM environments are already enabling just such an approach. Here, ‘loose coupling’ is what enables re-use, flexibility and adaptability.
The idea should be that these sorts of languages (BPML and BPEL) should pursue the old truism - that if it can be abstracted into the semantics of the approach, then it should. By introducing a change like BPELJ, IBM and BEA are taking things firmly back in the other direction - into the realms of programming that requires deep technical skill.
I used to have an adage that I used when looking at workflow engines. If you asked about something a little more difficult, they would say something like "that's easy, you have to write a program to do that". You'd get that answer for all sorts of questions - like asking how you would ensure the same actor received the work item if it navigated back to that role, or integrating even the simplest application.
All that this (BPELJ) shows is that the Application Server vendors and integration centric players have difficulty meeting the semantic needs of true BUSINESS PROCESSES. "How things get done around here" is full of all sorts of subtleties, and if you cannot represent it at the semantic level, then you have to resort to programming.
For those of us, who see a future where an executable business process language can enable a whole new approach to computing, the introduction of Java programming extensions within BPEL is a very retrograde step. Quite simply, it will ensure that the ‘standards’ end up having very little to do with the business and a lot to do with programming – thus sustaining the Business-IT divide. To me, the key point is not one of portability on platforms (one could argue that Java is portable). Instead, it is whether the engine can externalize the logic embedded in the Java.
The BPEL TC should resist this sort of attempt to divert its activities and focus their attention on solving the problems of the business process at the semantic level – giving the BPEL specification the sorts of process-oriented capabilities needed by business. At least then there is a chance for a whole new raft of software platforms that can present these semantics in an end-user accessible environment.
The TC should very explicitly reject the antics of vendors who want to divert its activities back towards developing yet another irrelevant guideline for IT programmers. BPELJ seems (at least to me) to serve only the needs of the existing application server and programming tool vendors – those who are most threatened by the emergence of business accessible computing environments.
|
|
|
Message #116524
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BEA and IBM submit joint white paper on BPELJ
One of the things that amazed me about deploying without UDDI a container of interdependent web services was how many URLs needed to be calculated and copied before execution began. But now I see there's JmDNS on SourceForge implementing standards defined by the Internet Engineering Task Force. I could easily forsee SOA embracing p2p and leveraging JmDNS or JXTA or Jini or WS-Discovery or WS-Resource, etc. In which case URLs are discovered. Can BPEL describe workflow that relies on discovery other than "the little-used UDDI"?
|
|
|
Message #116772
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BEA and IBM submit joint white paper on BPELJ
Derek
I could not agree more with your recommendations. For a change, we were starting to see standards emerge that were vendor independent, technology independent, platform independent, and protocol independent. What IBM and BEA are doing is just to protect their investments in their application server and integration platforms and lock the customers to the same. This should be strongly rejected by BPEL TC as an attempt to vendorize the standard. Is there a way we can create a campaign against this move?
N. Shekar
|
|
|
Message #197448
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
envex xflow customization expert
Hi.
We are here . http://www.genisofttechnologies.com
Use the Request a Quote Form in our HomePage.
We have already done xflow customization for many customers.
contact us , and we could give you reference of our customer list.
Thanks and Regards.
We are also expert in Visual Basic , Crystal Reports 3 tier Application Development .
Cheap ERP Development
etc.,
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
