I know what business is, I know what an object is, but what is a Business Object?!?
MattLuczkowiak 120000P9G8 Visits (2808)
As you may be aware, the primary way that data is represented within WebSphere Process Server is as a Business Object (BO). This is essentially a container that houses all the values of your data and can be manipulated or inspected within the various components that exist in WebSphere Process Server. This blog entry is to break down what needs to be understood about these Business Objects and how they are handled by WebSphere Process Server specifically. Please note, this entry is only directly applicable to EMF style BOs, not Lazy parsing style (this is new in version 7 of WebSphere Process Server).
The first thing to know is that Business Objects are represented as XML Schemas in WebSphere Process Server. For instance, if you are using the WebSphere Integration Developer (WID) to create your object, you can observe that once you have finished modeling your BO in the BO Editor, it has created an xsd file for you within the module. This is nothing more than an XML schema containing element and attribute declarations. These schemas can also exist directly in a wsdl file as well.
The reasoning for this is that when all these elements are loaded into the EMF system, which is what the BO as modeled in at runtime, these two things are what tells them apart. You can essentially think of a namespace as a big bucket in EMF. Every element and attribute that is defined in a namespace is tossed into a common bucket and is known from then on as a "feature" (more on this in a moment). The only caveat, is that there can only be one element or attribute with a specific name existing in this namespace bucket. So what essentially happens is that if you have defined two different elements with the same name in the same namespace, at runtime, only one of these will be usable. When a component attempts to use the other one, it will instead load the unexpected element and this is where problems can arise since this element may actually have distinct structures in each case. This them becomes a guessing game on which element will actually be loaded and used (and this ultimately will depend on the classloading policy in place).
There is a good technote that describes this behavior and a sample of how to remedy it:
WebSphere Integration Developer provides a good warning if duplicates do exist in the modules or a modules dependency, so this should help to catch most instances. However, when adding in shared libraries or other schemas just sitting in the server's classpath, this would need to be investigated manually. SCA and ArtifactLoader trace may be enabled to help in finding what is loaded and from where as needed.