The main idea behind the paradigm of thing orientation is that the object model is much too strict in some applications and in these cases we need more general software modules than objects. The white paper Ercatons: Thing-oriented Programming by Imbusch, Langhammer and von Walter introduces a new paradigm based on XML technologies, provides a theoretical background and describes an application.
XML Documents...
Before I explain these concepts let’s start with something you might know: the representation of a record in SAP Record Management. In fact your NW4 Testdrive contains the main package SRM and you can call records management with the transaction ORGANIZER and choose S_RMS_DATA. Unfortunately you won’t get very far without a Content Server and TREX and with the correct customizing. But studying the SRM framework is quite inspiring because it covers parts of the SAP standard in a neat way:
- business objects like RECORD and DOCUMENT,
- workflows and encapsulations of WAPI-functions (just study the function modules SRM_SP_WFL_START_WORKFLOW or CL_SRM_START_FRAMEWORK) and of course the
- service provider framework that allows user defined plugins (just look at the interfaces IF_SP_*).
This has nothing to do with thing orientation but it should be obvious to you that a record is a very complicated entity: It can contain text, links to different other records and documents, meta information, information related to workflows and so on. It is possible that a record can live in the SAP System as well in document management systems. So it won’t be surprising that SAP decided to store records as XML documents in a content server and manages them using the knowledge provider. The XML representation has various advantages:
- Records are extensible – we can add additional XML elements to them,
- we have a versioning mechanism by supporting different versions of an XML schema.
Here we can see how a very simple record could look like:
... and Ercatons
But what will happen if our program doesn’t treat a little XML document like that as a data container and instead as an agent that has methods that can be invoked by an engine? With XML we have a lot of possibilities. A method could be a
- an XSL transformation or
- SOAP calls of Web Services,
- ABAP code (like BAPI calls) that will be executed dynamically and
- non-XML resources in JAR files.
Such an agent could be able to live and interact on different platforms, could inherit its inner structure from other agents or delegate functionality to them. An agent could be morphed by an XSL transformation and could have diffferent presentations: An API as well as an HTML based user interface for human interaction. And this is the idea behind such agents called Ercatons:
I think for most business applications Ercatons will be the wrong way although Ercatons have been used successfully at Henkel company.
Today we need Business Process Experts to identify regular patters in business processes, create applications that can deal with them in standardized as well as customizable ways and finally we link applications using one of the known integration techniques. Within an business application we have to deal with mass data that are quite uniform. We use rule sets to guide workflows and automated processes. In every business application I created so far the business logic controlled the objects and not vice versa.
On the other hand it would be wrong just to look those business applications because they are our daily work and we have much experience with them. The SAP Netweaver Web Application Server and the whole Netweaver Infrastructure is so powerful that we can start to think about other innovative applications. Has someone a suggestion for a neat application of Ercatons prototype perhaps in ABAP?
Here's a further link to organic computing.
2 Comments
