I am fond of talking of two big problems I have had in the past with ESB style architectures: excessive mapping and issues managing state (active/transient state vs. steady state/long-lived storage).
The mapping you deal with in an ESB includes object to XML (OX) and object to relational (OR) and various object to object mappings. Update (few hours later) - forgot one: And if it is a message-centric ESB, active/transient state to your destination names (e.g., hierarchical Topic names).
It isn't surprising, but I'm finding that all of the same object to object mapping is still there with JavaSpaces + an object to object equivalent of OX.
The ESB systems I have worked on in the past had a canonical message format. All messages that bounced around the ESB conformed to this model. Some of the messages were small validations of particular data (e.g., address scrub). The main work flows, however, were large XML documents loosely following the ACORD XML standard (insurance industry XML guideline).
With JavaSpaces, the patterns you read about use distributed data structures. Instead of having a large Entry in the space you have many that are related to each other. You do this for transactional reasons, serialization reasons, flexibility reasons etc. Some of the objects I deal with are indeed very large. Doing a take on a large object only to navigate the object graph and flip a bit and do another write isn't performant or flexible.
So the "shallow" model (lots of small interrelated Entries) works great for UI input, address validation etc.
But there are also areas of the system (some key work flows) that would benefit from a canonical form - the "deep" Entry model. Rather than having each worker gather all the Entries up to make sense of them, you do this once and then write the deep Entry to the space and let various workers use it to walk it through a work flow.
But now you have to render it back to your UI that expects a shallow representation.
So the deeper I get the more I realize that JavaSpaces do not make the mapping angst I have encountered go away. The mapping is still there. It is certainly improved because it is object to object mapping that is easy to write unit tests for etc., but it is still there. Update (few hours later) And there isn't any active/transient state mapping to destination names so at least one is eliminated entirely :)
These same issues are also present with a distributed caching solution I believe.
Do I have this right or am I missing something?
10 comments:
Fuzzy,
All of that is great for an internally focused system, but what about when you want to interoperate with an external system? Will Javaspaces improve that painful mapping exercise?
The problem is in the dater, not just the technology. Imagine the case of a tank. To the mechanic, the tank is an aggregation of many different parts, each of which has specific attributes that affect how he does his job. To the general, the tank is an atomic unit which as a whole has specific attributes that affect how he does his job. It's still the same tank; it's just that different roles need to view it in different ways.
Whilst getting XML out of the mix doesn't change the difference in views between disparate parts of the system, it does lower the impedance between those parts. One way we solve problems in software is by adding a layer of abstraction and XML is an abstraction of the POJO. But that abstraction comes with a cost, whether the abstraction is XML for a POJO or a C++ class for a line voltage. As MWesty highlighted, that abstraction is more useful in interoperating between large organizations than it is in intraoperating inside an organization.
mwesty,
Not particularly - it is still there.
I think that it will be a bit easier as the concept we have been using is to defend the core system from the outside world. We do not want XML leaking into the core system because we don't think it provides value and comes with all the OX mapping we want to avoid.
What we want to do is to deal with services (e.g., external systems) that require XML or any other form of different mapping at the perimeter - but you still have to do it.
I think that in the end JavaSpaces provides a lot of value in the two key pain areas of mapping and state management. The key here is design. You can hurt yourself with JavaSpaces just like any technology. I think that just the fact that we are being very deliberate about these two aspects of the system alone is why this system will (hopefully) be simpler.
sarge,
Exactly.
So I think JavaSpaces is very useful in the core of an application and can certainly be used for all sorts of other things.
But competing across domains (even within an organization) is often best accomplished via XML.
Jini/JavaSpaces certainly doesn't replace everything although it certainly could. The nice thing is you don't have to go all or nothing. You can use both.
Hi Mike -
Perhaps you can give us some examples/use cases of where your pain points are with javaspaces and maybe even help to mold future specifications of Javaspaces or extensions. There was talk of an Extension called Executor, check the jini-user list to see if this sounds like it may help you?
Cheers
--Calum
Calum said:
"Perhaps you can give us some examples/use cases of where your pain points are with javaspaces and maybe even help to mold future specifications of Javaspaces or extensions. There was talk of an Extension called Executor, check the jini-user list to see if this sounds like it may help you?"
Yeah, there were several different propositions for Executor. I implemented a prototype for Blitz which would allow you to ship some code to the server where it would be executed against a JavaSpace proxy locally. So you got all your JavaSpace operations without the network hits.
These bits of code were leased and labelled so you could ship them once and then repeatedly invoke them and have them cleared out if the client died.
I still have the code lying around somewhere.......
Dan.
http://www.dancres.org
I will take a look - thanks Calum and Dan.
I don't think that anything I have here is an issue with the spec - it is just us learning more about the JavaSpaces programming model and distributed data structures and when to use what in an Entry (a "shallow" entry that is a piece of a larger logical structure distributed throughout the space (e.g., a line item) OR an Entry that includes a large object graph all contained within a single entry - "deep" (e.g., order).
Obviously JavaSpaces doesn't care which way you do it, but in building a large system, you want to figure out the right way to do it.
We have the "JavaSpaces Principles, Patterns, and Practice" book that really shows you the power of JavaSpaces.
It is just knowing what to do where that is challenging when you are a newbie.
JavaSpaces is the most malleable technology I have ever seen. This is fantastic. It can be both exciting and frightening because it is a blank canvas - it does not impose the solution on you directly so you must choose.
Fuzzy said:
"It is just knowing what to do where that is challenging when you are a newbie. "
Indeed and specs aren't really useful for that IMHO. I think it's compounded by the fact that the specs give the impression that things are complete in terms of form and function.
I certainly believe that JavaSpaces have some way to go in terms of evolving additional features to make exploiting the model to the max possible and to be clear, I'm not talking about adding JMS wrappers and such like.
Dan
http://www.dancres.org
...when to use what in an Entry (a "shallow" entry that is a piece of a larger logical structure distributed throughout the space (e.g., a line item) OR an Entry that includes a large object graph all contained within a single entry - "deep" (e.g., order).....
Potentially with the Executor extension you could write the order, and then use the Executor to extract line item and send you back entries represeting these items, without extracting the large order object from the space....of course that's just a very rough idea of what you can do, but ...
Hey thanks for the clarification Calum/Dan. I am gandering at Executor etc.
Post a Comment