I saw an excellent presentation on Seam, and aside from its integration with JSF and EJB 3.0, I was particularly interested in how they worked in JBoss's version of BPEL, jBPM. I'm not 100% sold on BPEL, but it definitely seems like a great way to reduce coupling and complexity in larger enterprise systems.
Anyone been using BPEL? Ready for prime time yet? Or was it a horrendous mistake that is now being undone? :^)
- Saish
> I saw an excellent presentation on Seam, and aside
> from its integration with JSF and EJB 3.0, I was
> particularly interested in how they worked in JBoss's
> version of BPEL, jBPM. I'm not 100% sold on BPEL,
> but it definitely seems like a great way to reduce
> coupling and complexity in larger enterprise systems.
>
>
> Anyone been using BPEL? Ready for prime time yet?
> Or was it a horrendous mistake that is now being
> undone? :^)
>
> - Saish
I've looked at it as a replacement for Tibco's BusinessWorks application which is one of the biggest dogs I have ever worked with. Before anyone asks, I don't have time to describe all the issues with that tool. Just know that it is extremely painful.
Having said that, the idea behind it is pretty good for a workflow type archtecture. BPEL seems to be a standardization of that kind of environment. The one thing that I would caution you on is trying to do too much in that kind of environment. It's not a replacement for a text based language like Java. It's a complimentary tool. If it is like BW (and I'm pretty sure it is) it excels at modelling high level transactions and business logic. We are talking coarse-grained steps here. Big time. Use good OO design to build the lower-level system logic (using Java most likely) and call it from BPEL.
Anyway, there are lots of free impementations. Give it a swing and let me know if I make any ddamn sense.
One thing that BW desperately needs is a good scripting-language (Python, perhaps) based activity. Some things don't quite warrant a whole Java object model and don't quite work with boxed and arrows either. You might want to look for a way to do that before you end up with a big mess, if you start using it.
I've looked at it as a replacement for Tibco's BusinessWorks application which is one of the biggest dogs I have ever worked with. Before anyone asks, I don't have time to describe all the issues with that tool. Just know that it is extremely painful.
The WYSIWIG editor for the workflow or the tool itself? (Or both, I guess)
Having said that, the idea behind it is pretty good for a workflow type archtecture. BPEL seems to be a standardization of that kind of environment. The one thing that I would caution you on is trying to do too much in that kind of environment. It's not a replacement for a text based language like Java. It's a complimentary tool. If it is like BW (and I'm pretty sure it is) it excels at modelling high level transactions and business logic. We are talking coarse-grained steps here. Big time. Use good OO design to build the lower-level system logic (using Java most likely) and call it from BPEL.
That's my initial impression as well. I remember reading in "Pragmatic Programmer" the idea of a 'blackboard' for really complex workflows and business transactions. To me, BEPL seemed a good way to implement a 'blackboard'.
At least in the original Seam presentation, Gavin King went over the various additional 'scopes' that Seam provides. One is 'between' request and session, called 'conversational'. Pretty slick in that it allows MDI usage of a web app without contentions in HttpSession. More pertinent to this discussion, though, was 'business process' scope, which was 'beyond' application scope. Bascially, he hooked Seam into jBPL to store incomplete workflows until they were ready to go to the database for storage.
Anyway, there are lots of free impementations. Give it a swing and let me know if I make any ddamn sense.
Definitely makes sense. And thanks for the as always salient reply!
One thing that BW desperately needs is a good scripting-language (Python, perhaps) based activity. Some things don't quite warrant a whole Java object model and don't quite work with boxed and arrows either. You might want to look for a way to do that before you end up with a big mess, if you start using it.
I'm thinking of handling large-scale events in the system (say when an application is completed and can be processed internally, then when ready for customer review and then final handling.) So, really, I'm thinking of using BPEL to represent large components in the system as state machines, governing the allowable transitions from one, large component state (or system state) to another for a given workflow. (Sorry to be vague, but I'm trying to keep things at a high level now).
I also think there's room for a rules engine somewhere in the mix. The workflow itself is fairly standardized, though there are multiple paths to a given component event. It's in each component that regulations vary from state to state or county to county. So it seemed to me that one could get a lot of bang for the buck via:
> Using EJB 3.0 for transaction management and JPA for O/R mapping. Much of the system already uses Hibernate.
> Use BPEL for high-level state transitions in workflow that are too complex to model in either EJB or POJO's, since most of the transitions are 'orthogonal' to the object model itself, similar to aspects.
> Use a Rules Engine for the complex variety of validations that occur in the object model itself. Again, so that the object model is cleaner and concerned with fewer duties.
Finally, it seems to me that one additional advantage, though I am dubious it can be achieved in reality, is that theoretically a business analyst can develop BPEL graphs and potentially write additional rules engine ... err ... rules if the grammar is English-enough.
Ah, I'm rambling. I'm just honestly excited about BPEL and not totally sure what the best use of it might be. :^)
- Saish
> Ah, I'm rambling. I'm just honestly excited about
> BPEL and not totally sure what the best use of it
> might be. :^)
If you have a very well designed set of abstractions for your processing flow, it's a great way to 'glue' the pieces together in a highly flexible way. That's a big 'if' that I can't say applies all that well to what I work on.
If you have a very well designed set of abstractions for your processing flow, it's a great way to 'glue' the pieces together in a highly flexible way. That's a big 'if' that I can't say applies all that well to what I work on.
Good points to keep in mind. It's getting good press but still seems to be in its infancy.
- Saish
> > Ah, I'm rambling. I'm just honestly excited about
> > BPEL and not totally sure what the best use of it
> > might be. :^)
>
> If you have a very well designed set of abstractions
> for your processing flow, it's a great way to 'glue'
> the pieces together in a highly flexible way. That's
> a big 'if' that I can't say applies all that well to
> what I work on.I
Exactly, in the SOA world they would call the abstractions "services". SOA is somewhat of a moving target, depending on who's selling what, but an article I read somewhere identified find, bind, publish, execute and orchestrate as the five core operations of SOA, BPEL (obviously) serving the role of the orchestrator. That's about as succinct a definition as I've heard for SOA. It would be really nice if we could keep things simple like that, but I think the crush of competing vendors and standards will keep things ...uh... "interesting" (as always) for us lowly computer hackers.
> Exactly, in the SOA world they would call the
> abstractions "services". SOA is somewhat of a moving
> target, depending on who's selling what, but an
> article I read somewhere identified find, bind,
> publish, execute and orchestrate as the five core
> operations of SOA, BPEL (obviously) serving the role
> of the orchestrator. That's about as succinct a
> definition as I've heard for SOA. It would be really
> nice if we could keep things simple like that, but I
> think the crush of competing vendors and standards
> will keep things ...uh... "interesting" (as always)
> for us lowly computer hackers.
Yeah, there's something to SOA for sure (not that's that new of an idea or anything) but I think it's a bit oversold. Definitely services would be something you would call as part of a 'process' but there are always going to be mundane tasks that will need to be done such as validation, transformation, data retrieval, etc. What i mean to warn against is trying to implement all of this in BPEL or SOA for that matter. SOA is a little oversold right now and my experience is that you add a lot of overhead when you go to a SOA model. Trying to implement synchronous transactions with SOA is difficult, at best. Possibly, I'm just seeing prro execution, but I feel that (for now at least) this is just fact for SOA.
Yeah, there's something to SOA for sure (not that's that new of an idea or anything) but I think it's a bit oversold. Definitely services would be something you would call as part of a 'process' but there are always going to be mundane tasks that will need to be done such as validation, transformation, data retrieval, etc. What i mean to warn against is trying to implement all of this in BPEL or SOA for that matter. SOA is a little oversold right now and my experience is that you add a lot of overhead when you go to a SOA model. Trying to implement synchronous transactions with SOA is difficult, at best. Possibly, I'm just seeing prro execution, but I feel that (for now at least) this is just fact for SOA.
Seems to me a lot of this can be handled with 'vanilla' MVC. Validation and transformation can occur in a controller. (Granted validation should also occur in model tiers as well so that validations are not 'lost' if a new client is created). Transformation on the other hand seems to me totally the responsibility of the controller. I have a view (or WSDL or whatever) that needs to be mapped/transformed to either a command or DTO for the service to act on. That's the contract the service defines. The controller presumably must honor the contract and map to its view/client.
Transactions and data retrieval seem are separate animals. I read a really good article on how Amazon did SOA. Bascially, a service 'owns' all model classes from the service itself, to domain objects, all the way down to a given database schema. So, my 'account' service will be the only component with access to the RDBMS 'account' schema. This promotes vertical component development and promotes ownership, both of which are (or should be) goals of SOA. Integration classes to third-party or legacy API's would follow a similar ownership pattern.
The remaining errata (exception handling, logging, auditing, authentication, etc) could conceivably easily be handled by a judicious use of AOP. That leaves the domain model as POJO's. BPEL is handling workflow. A rules engine is handling complexity best left out of code. One of your only remaining decisions is how to expose the service itself (WSDL, EJB, Pojo, Servlet, etc.)
Just a few thoughts. I'm not 100% committed to any of the above, but it's the latest incarnation of what I hope becomes a somewhat viable architecture. :^)
- Saish
> Seems to me a lot of this can be handled with
> 'vanilla' MVC. Validation and transformation can
> occur in a controller. (Granted validation should
> also occur in model tiers as well so that validations
> are not 'lost' if a new client is created).
> Transformation on the other hand seems to me totally
> the responsibility of the controller. I have a view
> (or WSDL or whatever) that needs to be
> mapped/transformed to either a command or DTO for
> the service to act on. That's the contract the
> service defines. The controller presumably must
> honor the contract and map to its view/client.
Assuming I understand what you are saying here, this is the point I am trying to make. The controller (the BPEL engine) needs to convert the data into the proper input format before sending it to the service. You can implement this conversion in 'pure' BPEL (unchecked assumption.) But there is no specific reason or benefit to implementing the conversion logic in BPEL. I will say from experience in BW, that such conversions should definitely be an abstraction and not hardocoded into a process defintion. Lastly, implementing data transformation as a SOA service is a poor choice so this is a place where a wel defined Java (for example) API fits.
> Transactions and data retrieval seem are separate
> animals. I read a really good article on how Amazon
> did SOA.
All I'll say here is that I a going to take advice from Amazon with a large grain of salt.
> Bascially, a service 'owns' all model
> classes from the service itself, to domain objects,
> all the way down to a given database schema. So, my
> 'account' service will be the only component with
> access to the RDBMS 'account' schema. This promotes
> vertical component development and promotes
> ownership, both of which are (or should be) goals of
> SOA. Integration classes to third-party or legacy
> API's would follow a similar ownership pattern.
Sounds like a fairly structured theory but my question is that is it proven in practice?
> The remaining errata (exception handling, logging,
> auditing, authentication, etc) could conceivably
> easily be handled by a judicious use of AOP. That
> leaves the domain model as POJO's. BPEL is handling
> workflow. A rules engine is handling complexity best
> left out of code. One of your only remaining
> decisions is how to expose the service itself (WSDL,
> EJB, Pojo, Servlet, etc.)
I could be wrong here but my assumption was that data in BPEL would be expressed in XML.
I think we somewhat got off the same page in the last two posts. BPEL is only a part of the architecture. Yes, it is in XML, and its focus is managing workflow and transitions between component or system state.
The controller I'm referring to is a 'vanilla' MVC controller. This could be JSF, Struts, Soap, etc. It would map to a domain object used by a given service. BPEL will presumably operate on the same services and domain objects, but not perform any transformation or mapping.
Just out of curiousity, any historical reason for your vituperative reaction to Amazon? :^)
Not sure if their model is proven in practice, but I like the emphasis on service ownership of everything M in MVC (all the way down to a database schema). In our environment, we have a lot of coupling and very little ownership, where a relatively innocuous change to one object (RDBMS or Java) can ripple in unforseen ways. Yes, this is the nature of the beast to a certain extent, but I think ownership will go at least some way towards obviating those issues. Then again, it might not.
- Saish
