Posts Tagged ‘REST’

Service Reuse

June 3, 2010 2 comments

Reuse is a topic which confuses a lot of people. Main reason for confusion is inability to understand the difference between component-based and service-oriented architectures. These have fundamentally different ways of reuse.

In component-based architecture, the idea is writing components with generic interfaces which can be used in different scenarios. So instead of implementing functions over and over, create a generic/abstract interface and reuse the function in different places. This works in different levels such as simple libraries (log4j, log4net, spring, etc), it works in large frameworks (drools, jpmn, workflow foundation, wcf, lucene, etc.) and also in infrastructure level (database servers, distributed caches etc). The idea is all same: generic stable interface, high configurability. Although this approach works very well with infrastructural components (doesn’t deliver business value directly), unfortunately, experience of the industry shows that it doesn’t work well with implementation of business processes (usually called as “business logic” in the language of this architecture style).

In service oriented architecture, reuse has a completely different meaning. Reuse of services is about existing consumers using newer version of the service. Reuse of services is “forwards” (existing consumers using new service versions) not “backwards” (new consumers using existing services). It’s not about how to implement generic services which doesn’t need to change for new consumers, it’s about how to implement services which can be extended without disturbing (upgrading) existing consumers. Therefore service compatibility and contract versioning are key concepts in service oriented architecture.

A weak understanding of services ends up with, for example, efforts to define generic service contracts. Because it’s practically not possible to know the unknown these efforts are just wasted. Usually this becomes guess-work, future-predicting. David Chappell says “Creating services that can be reused requires predicting the future…” and concludes that SOA doesn’t work. It’s very clear that he doesn’t understand the concepts of service-orientation. Similarly when Juval Lowy is excited about the capabilities of WCF and advertises the concepts “every object as a service”, same mindset presents itself. It’s not difficult to guess why WCF still doesn’t have contract-first web service development.

I noticed an InfoQ presentation “Expressing Service Capabilities Uniformly” which explains reusability as “multiple services implements same contract”. Funny that change of service contract is stated as a problem, and in the “cons” list you can find the difficulty of  change management. Of course, he doesn’t mention a word about versioning or compatibility. With his architecture style business process is reduced to “moving data from service to service” and REST is the savior. Same story over and over again…

Long story short, there are lot’s of people around who doesn’t understand service-orientation but claim it doesn’t work. Reuse is just one example. More to come…

Business Entity Definition Language from IBM

April 27, 2010 2 comments

Last week IBM published the first part of a Data4BPM series:

Part 1 of this series introduces the concept of business entities as a means of representing the business view of data. It proposes two new standards, the Business Entity Definition Language (BEDL) and BPEL4Data for the holistic design and execution of process with Business Entities.

This is definitely a good move towards embracing the importance of data model in business processes. I see this in the direction of connecting different models with the efforts from Ksenia Wahler in her paper “LinkA framework for integrated process and object life cycle modeling” and Bruce Silver in his articles “Integrating Process and Rules Part 1Part 2“.

As mentioned in the paper, instead of “process-first” or “data-first” approach, a “holistic approach will prove to be most effective. However, I don’t agree that holistic means process plus data. For me holistic would as well include business rules, motivation, etc. That would be modeling all columns of Zachman framework (what, where, how, …) For example “Discovering Business Entities” section is very weak, doesn’t tell one work about business rules. You can also see that state transition rules are fit into a single attribute inside access policies. This clearly tells me, there’s a lot of space for improvement in business rules area.

What I like very much in the paper is the concept of four components of Business Entity types:

  • Lifecycle
  • Information
  • Access Policies
  • Notifications

CRUDE style in access policies (create, read, update, delete, execute state transition) somehow matches REST style which could be applied in this context. Although REST is not an approach I would take for implementing services, data services as such could be a candidate.

The link with BPEL is another point of criticism. JJ made some comments about that in his blog:

Thinking that a “Business Process Whatever Language” needs extensions to deal with Human tasks or Process Data is not just comical, it is ludicrous […]