Eric Newcomer wrote: > Services are not objects, and I am only suggesting it would be helpful > to design the service first, and the object second. Maybe objects are > the best way to implement services, but I think objects tend to be more > RPC oriented, or more typically used for synchronous style interactions. > > I believe some proportion of the world's applications are better served > using asychronous interactions. Certainly you can use objects for this > - I am not trying to minimize the importance of objects in any way.
What's interesting about this perspective Eric, for me, is that it really indicates a bias about communications styles more than about objects. Again, I'll state that people with CORBA (or other focused technology based) experiences, trying to drive a point, should really try hard not to use the term Object or Object Oriented without also including CORBA (or other appropriate term) as part of the terminology. Our own personal biases, driven by bad experiences are much more productively discussed using specific examples rather than glaring generalizations which only serve to cloud the issues, or eliminate recognition of the real problems that need to be addressed. > But > I think it helps abstract thinking to design a service independently of > whether it will be implemented using an object or a message queue. There are many reasons to avoid focusing on technologies too early. But, there are also many reasons to focus on the attributes of specific technologies early on to help you make sure that a particular technology is either a benefit or a problem. Knowing whether a technology supplies asynchronous comms, might be important when you are considering it for some other attribute that you also need. So, I think it's important to have a wide range of technolgies to consider the features of so that you can find the appropriate feature combinations which provide all the attributes that you need including cost, time to "running system" and maintence and long term strategies. > If you are always designing things in objects I think you might miss one > of the main benefits of services, which is a higher level of abstraction. I design objects, first by the services it provides to the world, using interfaces, because I use Java for my SOAs. I then have something that I can hand to developers immediately to get started with fleshing out the operational aspects of the required service behavior indicated by the API. But, I also, on many occasions create my own stubbed off test classes using these interfaces for validation of the design, preliminary tests regarding latency and many other attributes that I consider important. Waiting forever to get to code means that the investment you have in getting there can be so large as to force you down a design path which is really not the right path because it is too expensive to back up. So, you might be forced to switch from async comms to sync comms because of lack of synchronization you forgot about. It might cause you to have to use transactions in an async comms environment where non-transactional sync comms would be less overhead. You have to try things out and see... > I just think modeling, designing, and thinking about everything in terms > of objects is overkill, too complex. But maybe this is because I am > kind of an old guy, and I remember the world of IT before objects were > in it. I grew up in a world without objects. It small and simple to do simple things back then. Now that all the simple things have been done, we have more complex things to solve/do. That means more elaborate tools and different strategies are needed. Elaborate tools are not always software tooling as much as different work ordering and practices which make it much faster to find the information which you need to make the right decision. When I'm designing an architecture, I really don't like waving a wand and saying we'll do "this" without having practicle experience with using "this" in exactly the way I'm planing to. If there is no software to test such a thing with, you have to create it. Having your software contracts and interfaces already defined makes it faster to stub things off. So, doing your architecture/interface/servie design using a software interface description is not a bad thing. It's just different than what we've always done with so much paper design and brain design which results in less real experience/knowledge about the attributes of such architectures. Gregg Wonderly
