John Reynolds's Blog: Web Services and XML Archives

Human Powered Services (HPS) are the piece of the puzzle that meshes BPM with SOA... With HPS in the mix choreographing Human and Autonomous services is seamless, without HPS in the mix choreographing Human and Autonomous services is a pain.

Continue reading at my other blog...

Human-Powered Web Services

Posted by johnreynolds on November 18, 2006 at 11:13 AM | Permalink | Comments (6)

As SOA has become a more mainstream IT concept... you might even say a more mundane IT concept... there has been a lot of thought put forth on the creation of Composite Applications.... collections of distinct Services that are orchestrated and choreographed together (using BPM technologies) to implement some "higher-level" business functionality.

Many of these Composite Applications need user-interfaces, just like "normal" applications, but fortunately the transition from building a UI on top of objects (often EJBs) to building a UI on top of Services (often Web Services) is generally not that hard for programmers to make. Perhaps the biggest adjustment is in moving from a world where pass-by-reference was possible to a message-oriented world where everything is pass-by-value... but that's not really much of an obstacle for good programmers.

A more subtle aspect of user-interfaces and Composite Applications becomes apparent when you start to consider the Services that make up the applications. Most of the folks that I talk with tend to think of Services as automatons... fully automated tasks carried out by machines. This is especially true when I use the term Web Services... Everybody knows that a Web Service has nothing to do with people, it's just a machine at the "other" end of the line.

I'm going to suggest that conceptually limiting Web Services to automatons is a mistake that has hampered our ability to benefit from all that SOA has to offer. Our shared belief that Web Services are "always" automatons has impacted our conception of Composite Applications and has even impacted the design of most of our development environments (IDEs).

That's a pretty strong statement, so I'd better try to explain myself. Perhaps an example is in order....

Let's say that you are building a Composite Application to process an Order of some sort. Also assume that your customers speak many languages, and that it's necessary to translate each order to a common language before it is processed. To make this process pretty darn simple, let's also assume that Services are available to translate the orders from one language to another. Piece of cake... just funnel the order through the Language Translation Service and you're done.

Any good Service-Oriented IDE (such as NetBeans with the Enterprise Pack ) can handle the above process with ease. The IDE's tools make it relatively simple to orchestrate the process using BPEL, and relatively simple to build a UI on top of the BPEL (it's a Web Service after all). In short-order, you've created your Composite Application and all is well in the world.

So where's the beef? What's wrong with this picture?

Nothing really... until you start to consider the creation of the Language Translation Service with your IDE. Our conception of Web Services as automatons causes few problems when consuming the Services, the problem becomes evident when creating them.

I picked Language Translation on purpose... It's hard. Go out to any of the free translation services, translate this page to another language and back again, and you will see what I mean. Language Translation (at this point in time) is better performed by a person than by a machine.

Here's the previous paragraph translated to Spanish and back to English:

"I chose the translation of the language in intention… He is hard. Leave to the free services of translation uces of, again translate this page to another language and posteriora part, and you will see what I mean. The translation of the language (to this point in time) is made better by a person than by a machine."

So back to my example... Let's assume that the Language Translation Service is best performed by a Human (at this point in time). We still want a Web Service interface... we want to be able to consume this Service from within any Composite Application (and not change our application if at some point in the future machine translation becomes better)... but we also need a human-oriented interface for the person who is actually going to translate the Order.

Try building a Human-Powered Web Service with your IDE. You can do it, but it's tough. You're going to have to cobble together something that links together a human-oriented application with a Web Service, and it's probably not going to be pretty. This "ugliness" really shouldn't be a big surprise, because we've never thought of doing such a thing (maybe "never" is a bit strong... but not very often).

Now that I am spending much more time as a Business Process Guy, I'm finding the need for Human-Powered (Web) Services isn't rare at all. All of the good BPM suites (like Lombardi and Fuego) erase most of the distinctions between creating Human-Powered Services and creating Autonomous Services because most business processes are a mix of both types of Services.

Unfortunately, at this time there aren't widely-adopted standards for Human-Powered Services (HPS)... the BPM suites are proprietary and the concept of a "stand-alone" HPS seems alien. There's a good reason for that... when an HPS is invoked, the Human has to "know" that there is work to be done and that implies a notification mechanism like a task list or email.

I don't want to imply that it will be "easy" to come up with standards for Human-Powered Services... just look at all of the turmoil surrounding "BPEL for People"... but it is time for us to start addressing this class of Service in our IDEs. In this blog entry I have focused mostly on the creation of the HPS... but there are also some issues of consumption (people tend to be much slower than machines).

What it all really boils down to is wider awareness of Process-Oriented concerns... business processes are made up of automated and human-performed tasks, and we need to be able to implement both types of tasks in a manner that allows them to be consumed by a multitude of applications. That's what SOA was really all about in the first place.

(cross-posted at Thoughtful Programmer)

Process Driven Design and JBI (Java Business Integration)

Posted by johnreynolds on April 21, 2005 at 08:27 PM | Permalink | Comments (0)

I am a big advocate for Process Driven Design. I was disappointed that PD4J didn’t turn out to be all that I had hoped for, but I still believe in (Business) Process Driven Design as the key for delivering solutions that are good for both business users and IT departments.

People tend to focus on details. If you approach someone and ask them how to improve an application, they will most likely point out some detail of the application that bugs them. Maybe they have to look at two screens to get all the data that they need:

“Could you combine those fields on a single screen?”

There is nothing wrong with requests like this, but I think the way we deal with these requests is at the heart of software’s complexity spiral.

We have to keep in mind the Big Picture… or more precisely the Big Process. The request: “Could you combine those fields on a single screen?” needs interpretation:

The design of the current screens does not match the Process that the user is engaged in.

When we are asked to make a change to an application, no matter how seemingly trivial, we should evaluate that change in terms of how it will impact the processes that are being aided by the application. Some applications, like wizards, are clearly the embodiment of processes, but others, like your email application, aren’t so clear (especially when email is an integral part of many of your business processes).

Process Driven Design begins and ends with the process the business wants to accomplish. At each step of design and implementation there is a conscious link between the details and “why”. The answer to: “Why are the fields on two screens instead of one” should be traceable from the code that implements the screens to the process(es) for which the screens were created.

One of the great things about Process Driven Design is that the requirements phase transitions smoothly into the implementation phase and visa-versa. The business process diagrams, whether UML activity diagrams or process flow diagram, insure that both the users and the developers agree on the big picture. The relationship between implementation details and the big picture requirements are more apparent, making it easier to answer implementation questions. As a bonus, it’s also easier to see the ramifications of changing requirements.

Process Driven Design can’t really succeed without a tailored infrastructure to support it. We need an “operating system” that portrays the underlying environment as “process friendly”.

Providing a “process friendly” environment is where Service Oriented Architectures come in. Services perform the individual tasks that make up each process. The middleware that routes messages to services, and which enforces loose coupling between those services functions as the “operating system”. One term that is gaining acceptance for these “process friendly operating systems” is Enterprise Service Bus (ESB).

So now we have Services and an ESB to expose them for use. The next piece we need is a Process Engine.

Java is a general purpose language suited to a wide variety of tasks. Normally that’s a good thing, but to keep things clear we need languages tailored for the task. That’s where BPEL and UML Activity diagrams come in. Pictures and words together can more effectively define a process then words alone. A Process Engine executes process definitions.

Due to events in the industry beyond the JCP, PD4J morphed into BPELJ. BPELJ provides the specification for implementing a process engine. The “nice thing” about BPELJ is that is allows you to combine “Web Services” and Java based services in the same process. I don’t like BPELJ because I consider it to be messy to mix BPEL and Java, and the approach is a half-measure (What about C# or COBOL services?).

ESB (Enterprise Service Bus) proponents take a different approach. Instead of modifying the process language to accommodate specific languages, adapters are created to connect between services and the middleware infrastructure. In Java-based ESBs, these connectors are usually implemented using JCA (the J2EE Connector Architecture) and messaging within the ESB is handled via JMS (Java Messaging Service).

The JBI (Java Business Integration) specification is the closest thing we have to a "standard Java ESB".

JBI combines "pluggable SOA Integration components with a SOA infrastructure layer, JSR 208 provides the essential building block for implementing a standards-based ESB. It also paves the path for Java middleware vendors to leverage emerging technologies such as BPEL in their ESB offerings using consistent, standard interfaces."

It's too early to tell if JBI is going to catch on, but I'm very hopeful. PD4J and JBI may not be perfect, but they're getting us closer to an infrastructure where Process Driven Design can thrive.

A second look at BPELJ

Posted by johnreynolds on May 13, 2004 at 05:03 AM | Permalink | Comments (0)

I have had time to re-read the joint IBM and BEA whitepaper on BPELJ. My initial reaction was "Yuck". Intermingling Java snippets with XML invoked a gag reflex, and it was hard for me to keep reading. I missed the relationship between JSR 207 and BPELJ.

I cannot include examples from the whitepaper in this blog, the copyright explicitly states that no part of the document may be reproduced or transmitted without the explicit consent of BEA and IBM. Forgive me, but I will have to paraphrase. I encourage you to read the whitepaper to get a clearer idea of what the authors have proposed: "BPELJ: BPEL for Java technology"

The authors of the BPELJ whitepaper lost me with their opening statements:

BPELJ enables Java and BPEL to cooperate by embedding snippets of Java code into BPEL documents.

This statement is almost as attractive to me as the idea of embedding Java snippets into HTML pages. Paul Brown's blog on BPELJ mirrors my opinions.

The following statement is more compelling: BPELJ will make it possible to use BPEL to orchestrate long-running interactions with Web Services and J2EE components. This is a good thing.

BPEL uses "partner links" to enable web services to collaborate within a larger process. BPELJ adds "partner links" that use Java interfaces in addition to WSDL port types. A simple example of this would be a process that incorporates Web Services and Session Beans. With generic BPEL, each Session Bean must be wrapped in a Web Service to participate in a process. With BPELJ, any Session Bean can participate in a process without a wrapper. In addtion, serialized Java objects can be passed between the Java services rather then limiting all messages to XML documents.

This is a very pragmatic approach. BPELJ processes give up language neutrality to make it easier to use legacy Java components. BPELJ processes also promise to execute more quickly (assuming that the marshalling Java objects is faster then parsing XML payloads).

I have a philosphical problem with including Java snippets in BPELJ, but I understand the intent.

The justification for Java snippets is the plan to use BPELJ as the notation for JSR-207 Java class annotations. Annotations will be used to define BPELJ fragments for specific classes (much like XDoclet tags for EJBs). With the proper BPELJ annotation, any POJO class can be transformed into a process step... No need for a Session Bean wrapper, just annotate the POJO and it can be deployed into a BPELJ "container" (much like EJBs and their containers). I have to admit that the concept is pretty cool.

BEA is firmly commited to BPELJ and will be supporting it in the next major release of WebLogic Workshop. BPELJ was designed specifically with BEA's JPD and JSR 207 in mind.

Will the benefits of being able to use Java specific interfaces as process steps outweigh the benefits of language-neutral services? Processes are comprised of steps that implement business logic. In the environment where I work, the flexibility to reuse our business logic across heterogenous systems is pretty valuable. I may implement "Java only" interfaces for some minor services, but I imagine that I will generally wrap our key services in XML interfaces for wider reuse.

On the minus side, I am wary of BPELJ because it mingles XML and Java, and because I miss the language-neutral flexibility. On the plus side, I understand what the proponents are trying to accomplish, and I support their goals. Hopefully I will learn more at the BEA eWorld session on BPELJ on May 27th (in San Francisco).

There are some good concepts here. Let's hope the JCP process will iron out the kinks and deliver something we will all be happy to use.

The authors of the IBM/BEA whitepaper state that BPEL does not try to be a general-purpose programming language. They assume that BPEL should be combined with other languages to implement business functions. I can agree with that statement, but I think they have erred in their interpretation of what "combined" means. I believe that the BPEL authors assumed that business functions would be embedded within the Web Services that BPEL orchestrates. The implementation of these functions would be hidden, making it irrelevant what language was used. In contrast, the BPELJ authors feel that languages should be used to extend BPEL itself, to make the combination a general-purpose language. This seems like a very problematic position.

Extending BPEL to allow the control of Services that can use language specific interfaces is a good concept. Embedding language specific logic within a BPEL document goes much further, and is an idea that should be widely debated and discussed by the Java community.

Other blogs on BPELJ:

Coding for your own legacy

Posted by johnreynolds on April 30, 2004 at 06:26 AM | Permalink | Comments (2)

I fear that most programmers (myself included) usually think of the word "legacy" as something bad, as in the following article:
Do your customers have legacy COBOL applications written around the time King Nebuchadnezzar II built the Hanging Gardens of Babylon?

Legacy doesn't have to be a bad word, as is seen in The American Heritage® Dictionary of the English Language:

leg•a•cy

Something handed down from an ancestor or a predecessor or from the past:
"a legacy of religious freedom." See Synonyms at heritage.

What are you doing today to insure that the programmers of tomorrow don't curse that @#%!! legacy Java code that they're stuck with?

Based on my own astute powers of observation (and my gut feelings), I will hazard to publically predict that the programmers in the distant future (say five years from now) will not all be using Java. I further predict that the many programmers who will be using Java will not be using the primitive dialect that we currently employ.

With this limited knowledge of the future, how can I increase the odds that my coding efforts will be appreciated rather then cursed? To answer this question, I took a look at my least favorite legacy "assets" and tried to put my finger on what annoys me most.

Many of my least-favorite legacy applications have poor documentation. If you want to make a future programmer happy, explain what your code does and how to use it in clear and concise terms.

Hard to generate inputs and hard to parse outputs are guaranteed to produce expletives rather then praise. I once wrote a "survey" application whose output was serialized C++ objects. A companion application, also in C++, reinstantiated the survey objects to populate a database (The "surveys" were mailed to consumers on floppies. When the consumers mailed the floppies back, the results were retrieved). This was a great idea until the company switched to Java. If I had added code to produce ASCII output (this was pre-XML days), I would have been cursed less often. Efficiency does less to assure a good legacy then interoperability.

Several of my least-favorite legacy applications are bound by Graphical User Interfaces. GUI applications are notoriously difficult to integrate with anything else (see the blog by Rich Burridge for specifics): Contrast reusing GUI applications with reusing the CLI shell utilities that are so prevalent in Unix environments. I'm not suggesting that GUI interfaces aren't appropriate, just that life is easier when designers include command-line interfaces or programmatic APIs to access the core functionality.

Finally, my least-favorite legacy assets often do more then they need to. Sometimes the programs have bizarre side effects, but often the problem is that the original designer didn't distill the functionality to its essence. It's like having to pay for a reverse-osmosis purification unit when all you need is a water heater.

We can't guarantee that our heirs will value our code, but with the benefit of hindsight we can improve the odds.

All this leads me to think that embracing the Service Oriented Architecture paradyme will reduce the chances that I will be burned in effigy some day. SOA is defined in an IBM article as:

SOA is - "an application architecture within which all functions are defined as independent services with well-defined invokeable interfaces which can be called in defined sequences to form business processes."

The experiences that Calum Shaw-Mackay relates in his blog on The Great Theoretical Architecture resonate strongly with my own. His distilled design mantra is simple:

"this is my service it does X, and when you tell it to do X with this data, it does something and gives you this back"

Perhaps if I design my applications with "service orientation" as my guiding principle, then the legacy of code that I pass on will be appreciated instead of endured.

BPELJ - Good idea or bad dream?

Posted by johnreynolds on March 25, 2004 at 02:25 PM | Permalink | Comments (0)

IBM and BEA have just released a joint white paper on BPELJ, a combination of BPEL and the Java programming language:

BPELJ: BPEL for Java technology

This may be a really good idea, or it may be the worst mismash since JSP was introduced.

I'm a fan of BPEL (Business Process Definition Language), and I really like the process definition features in WebLogic Workshop 8.1, but I'm not so sure about BPELJ. Apparently, IBM and BEA feel that BPEL is not sufficient by itself, so they are encouraging authors to embed Java "snippets" into their XML. This gives me flashbacks to JSP in the pre-Tag library days, and I can only shudder at the thought that somebody will propose the addition of tag libraries to BPEL.

My concerns are probably moot, since it is pretty clear that BPEL and BPELJ are intended to be read and edited by application development tools rather then by mere mortals. No doubt the next version of WebLogic Workshop is already outputting these files.

Update: See my later thoughts on BPEJ.

UML and Process Definition for Java - JSR 207

Posted by johnreynolds on November 14, 2003 at 11:01 AM | Permalink | Comments (3)

Martin Fowler's blog on the Unwanted Modeling Language caught my eye and prompted me to re-examine my own feelings about UML.

I've never been really fond of UML. I am fond of the less formal "CRC Cards" approach, and I'm drawn to the ideals of Extreme Programming. If I knew more about Agile Modeling I would probably embrace it.

I was introduced to UML before it was called UML. Booch and Rumbaugh had not made peace yet, and you had to choose between "Fluffy Clouds" and OMT. OMT bothered me because it was not mandatory to specify the class interfaces. It also bothered me that I was encouraged to specify the data elements (attributes). To me, that violated what I considered the tenets of Object Oriented design. OMT had a data modeling feel to it and seemed to pay too much homage to Entity Relationship Diagrams. Perhaps this was more a failing of my instructors then of the methodology, but I never quite got over the bad first impression.

Over the years, UML tools became better (and cheaper), several new diagram types were introduced, and I somewhat resigned myself to the ubiquity of the "Rational Unified Process". I still ranted at the inability of tools to reliably extract UML diagrams from existing code (round-trip-engineering), but essentially I gave in to the pressure and shut up.

Why then did I race to read Martin Fowler's blog when I saw the tag "Unwanted Modeling Language"?

UML 1.x provides nine standard diagram types (UML 2.x raises the count to 13), but I’m really only “fluent” with three:

Class Diagram
Use Case Diagram
Sequence Diagram

I have found all three of these UML diagram types to be useful, but I have never found them to be integral to my development process. Inevitably the diagrams languish once "real development" begins, and if I need them later I reconstruct them from the code. I'm definitely not in the "UmlAsProgrammingLanguage" camp, and most of my colleagues prefer to "read the code" rather then fire up a UML tool. Javadoc is our preferred communication tool.

Perhaps better tools would change my habits, but there is still a big stumbling block for me.

Simply put, I have not mastered a UML diagram type that lends itself to the aspects of programming that I deal with most often. I gather a lot of requirements from users, and I design a lot of user interfaces. I have not found UML diagrams particularly helpful for either task, but have to admit that I really ought to learn more about the Activity diagrams.

"Activity diagrams are business process diagrams and track the flow of individual software objects from internally generated actions in a business context. They are often used to expose parallel and concurrent activities in use cases."

Most of what I deal with involves defining or understanding processes. User interfaces are very process oriented because they deal with the communication between humans and machines, but I think that it's safe to say that most programs implement a process or part of a process.

The UML activity diagrams seem well suited for my work, but there is a huge drawback (in my opinion). Nothing in the activity diagram is tied back to the source code (or visa-versa). You can't generate source from the activity diagram (not that I would really want to) and more importantly (for me) you cannot generate an activity diagram from source code.

Perhaps JSR-207 will change things and provide the kick in the pants that will drive me to master the UML activity diagrams.

"Process Definition for Java will build on Java Language Metadata technology (JSR-175) to provide an easy to use syntax for describing a business process at the source code level for the J2EE platform. Metadata will bind data and tasks within the process definition to variables, classes, and tasks in the source code. The metadata will be amenable to manipulation by tools."

JSR-207 (also known as PD4J) is still a work in progress, but it is based on BEA's Java Process Definition and close to fruition. JPD is included in Weblogic Workshop 8.1 and supports the following Process Definition Constructs:

Client Interactions
Control Interactions
Branching
Looping
Business-level parallelism
Blocking for one of multiple events
Transparent access to custom code
Arbitrary grouping of nodes
Exception handlers and timeouts
Explicit JTA transaction blocks

JSR-207 is limited to J2EE. It doesn't define a standard Process Definition Diagram, but I think it could definitely nudge UML tools in that direction. I've seen the modeling tools in Weblogic Workshop 8.1 and the process diagrams have been instantly embraced by my business owners. I love the idea of being able to navigate between a process diagram and the source code that implements a specific step of the process. The more that I can associate a piece of code with what it does for the user, the more confidence I will have that I've implemented what the customer wanted.

Another push for standardized process definitions comes from the Workflow Management Coalition's XML Process Definition Language - XPDL 1.0. From their press announcement

"Together with other WfMC standards, XPDL provides a framework for implementing business process management and workflow engines, and for designing, analyzing, and exchanging business processes."
"XPDL 1.0 uses the popular XML language to describe a business process. A process defined in XPDL (a set of XML statements) can be imported into any workflow engine that supports XPDL. The related objects and attributes (data associated with the process) are now also included in the XPDL process definition. The XPDL process definition can be generated by workflow modeling and simulation tools, or can be manually coded, or can be exported from another XPDL-compliant workflow engine." Read the article...

This is great stuff and I sure hope the JSR-207 and XPDL groups are talking to each other.

Much of the code that I have written has "died young' or been "stillborn", and unfortunately the same is true for many of my colleagues. There have been many reasons for this (changing technologies, company deaths, etc.) but I believe that in many cases I have been asked to develop software for a poorly thought out business process, or I have developed "tunnel vision" and implemented software that did not really match the desired process.

Perhaps a stronger linkage between the business process definition and source code implementation will produce applications that will live longer. At the very least, it should make it much easier to develop modeling tools that are valuable throughout an application’s lifecycle.

Update: See my later thoughts on BPEJ.

Powered by
Movable Type 3.01D

java.net RSS Feeds