This post stems out of a thread that Paul Szego started, in which rudy posed some questions about components and application layers, and which is probably dead, so I thought I'd start a new thread and share some of my experiences.
Firstly, business domain specific objects/components can not be reused across applications for the very simple reason they contain business specific data and if you 're-use' the object you must replicate the data, and data replication doesn't scale and is generally a bad idea in OLTP systems. Thinking back, I'm astonished we even tried.
So if I a create a customer component, I can not reuse it, but I need reuse. Every major application in a typical enterprise needs customer details. Every major application in a bank needs to debit/credit account. Every major application in a health care domain needs to charge insurer. I have never come across a business (domain) where the need to reuse things wasn't widespread.
There are essentially 2 solutions to this problem. One is to install a SAP or JD Edwards or Oracle ERP type application that satisfies most of the enterprises requirements (how much they actually satisfy is open to debate). Integration is built in to the application and all parts get their customer data (for example) from the same source. The other approach is to recognize that we need to engineer reuse into our applications and that reuse is of what the application does, the fashionable term is service, although this kind of reuse has been around for a long time and this is what System Interfaces do. There is a third option which is we build ad hoc interfaces which is the prevalent and generally unsatisfactory and not to mention costly default solution. Which brings me to my second point.
If we engineer (design) reuse then we need to explicitly decompose our requirements such that we resolve them to services (otherwise services become ad hoc, after the fact, and lets hack something that works). Services must be large grained and capable of answering complex (large grained) questions. There is an issue here with object granularity that I will come back to. So we need a design process that creates a thing that delivers services. Many people, myself included, use component to mean this thing and I think that is what rudy was meaning when he referred to component. Paul then interpreted component to mean a UML component. In UML a component is an implementation level artifact â essentially a package. Which brings me to my third point.
UML components are useless for modeling components as business (domain) level abstractions that provide large grained services - I speak from experience. Note that at this stage when decomposing requirements into services, all we know about a component is the services it provides, we know nothing about its implementation (separation of interface and implementation). FWIIW I have use collaboration diagrams, with the assumption the objects in the collaboration diagram are (large grained) components.
Coming back to object granularity. The reality is that objects (at least in J2EE environments) are fine grained. To take customer (party) as an example. If I want to ask a complex question such as, 'how many children resided with the customer as of a particular date' then it needs a number of objects to be coordinated to answer this question. In a J2EE environment these coordinators are the stateless session beans that rudy referred to (I wrote a paper on this which unfortunately has just been taken off line by my old company). Services are fundamentally stateless because if they are not you can not get reuse, hence stateless session beans.
The (probably mis-named) application layer rudy referred to, is the stateless session beans or equivalent that (collectively) provide these large grained services.
So to wrap up, reuse is of services provided by some implementation we call a component (implementation arbitrary). No enterprise level development should ignore the widespread need for reuse (otherwise you get application silos as documented in the Anti-Patterns book).
And the relevance to FDD? Well, Paul made a statement in the earlier thread that the dependency is from SI to PD, i.e. SI is dependent on PD, but not the reverse, which is true in FDD. However in service based development, which emphasizes and facilitates reuse and the integration of applications, this dependency is reversed
Phil
Some concerns
I believe that we have to devide the concept of reusability between at least this two qualifiers:
* Adaptability
* Usability
1) By Adaptability I mean the ability to reuse a Business Object or Service by changing some predefined logic to fit a new Business Scenario.
2) By Usability I mean the ability to reuse a Business Object or Service to fit a new Business Scenario while not changing its logic.
When we talk about reusability in software I usually think around 1) not 2) That is I don't think that an object such as a Knife is reusable but I do believe that can be used to fulfill different goals.
"So to wrap up, reuse is of services provided by some implementation we call a component (implementation arbitrary). No enterprise level development should ignore the widespread need for reuse (otherwise you get application silos as documented in the Anti-Patterns book)."
Phil it seams that you are targeting 2) with this statement which ofcourse I agree with your conclusion, neverthless you start from a precept of resusability that seams un-natural.
So IMHO both reusabilitiy of Business Objects or Services suffer the same problems within the scope 1). It has little to do with being state or stateless, but that business rules are inherinhantly complex to adapat or to extend in order to fit new business contexts required by different types of businesses (A Banking environment is different enough from a Insurance environment to disrupt reusability).
Now within the same business context, Banking for instance, one can actually develop an adaptable framework to fit the needs of multiple Banks (this is what SAP as done for each vertical market). This is what have done with Content Management and other types od applications.
The recent advent of Web Services actually are IMHO interpreting reusability as 2) too, and this is basically is usability, that is the ability to be used in different contexts as is (not adapatable).
Nuno Lopes
Adaptability and (re)-usability
Nuno
Yes, I am referring to 2) - what you call 'usability'.
On the subject of adaptability, which i refer to as flexibility - I think flexibility (adaptability) is generally a bad thing in software applications, despite clients regularly asking for it (and developers trying to build flexible applications). In Jeff's latest newsletter he references a study that showed most features in a typical application are never or rarely used. I think persuing the spurious goal of flexibility is part of the reason.
One thing I really like about the Agile movement in general and XP in particular is its emphasis on minimal solutions - 'The simplest possible solution that works!'
Once when I was told by a client to 'make sure the system is flexible' (for the nth time), I tore a blank page out of my notebook and handed it to the client and said 'This is the most flexible system I am aware of!'
Phil
SI not dependent on PD
Hi Phil,
Paul made a statement in the earlier thread that the dependency is from SI to PD, i.e. SI is dependent on PD, but not the reverse, which is true in FDD. However in service based development, which emphasizes and facilitates reuse and the integration of applications, this dependency is reversed
I *strongly* disagree with this point, and believe that PD should not be dependent on the SI.
I think the previous discussions are mixing issues together at several different levels and overloading terminology, which may be causing some confusion.
I was talking about a relatively low-level issue when I was discussing the PD-SI interface, and was focussed on the overall structure of this interface, and the incomplete paper backed it up with some Java code as an illustration.
I hesitate to say it's purely an implementation level issue, as the approach we take changes the nature of the interface from being focussed on the technology to a higher level of abstraction - to the "business" level.
That may be where the confusion comes from, but I'm only talking about the level of abstraction we use at this interface. I'm not talking about any kind of packaging or bundling of the functionality required at this interface into services or components. If this happens at the PD-SI interface then it's done in a way that suits the PD, with absolutely NO regard for how the functionality is packaged in SI.
It's not uncommon to have some kind of mapping between PD's breakdown of the interface and the packaging of the SI implementation. One common scenario: the SI layer might organise an implementation around the external system it talks to and/or the technology used to talk to them.
Say the PD layer defines ISystemInterfaceA and ISystemInterfaceB with a few methods in each. The PD layer builds ExternalSystemOne and ExternalSystemTwo, but these don't correspond to the PD interfaces. SystemOne might might implement some methods for ISystemInterfaceA and some others for ISystemInterfaceB, and similarly for SystemTwo. We'd write some adapters in the SI layer to map between them. This would all be transparent to the PD layer.
This happens a lot - typically whenever there's one of the enterprise-wide "warehouses" we need to go there to identify things and get back basic info, but then go to other systems for more specialised data. Say looking up a customer by name and then retreiving their credit rating. PD might bundle these into a "customer stuff" interface, while SI would actually have to go to two different places to satisfy this.
If you're saying that the availability of packaged external "services" should impact the way the PD is written, then no way! Obviously there's a dependency in that these requests must be able to be satisfied *somehow*, but I don't think the specifics oh how or where they're satisfied should matter. That's what gets us overly brittle "distributed" systems - and remember we multiply this instability for each new system added to the mix that takes that approach.
BTW this is certainly not specific to FDD - it's just a fantastic technique to be used whenever you've got a layered architecture of any kind.
Your post mentions business components, UML components, services, business objects, fine-grained objects, and EJB session beans. All very different beasts. I don't think I agree with some of your other points - it's hard to say since I think we're comparing apples and oranges here - but I'll continue that in another post.
Regardless of what the external system is or how we represent it, the requirement from PD should remain unchanged. It is precisely PD's indifference to the nature of the SI glue that gives us the independence I speak of so often. The SI code might be talking to some nicely defined service offered by another system, e.g. as a web service or an EJB session bean, or it might just be playing in a local datbase. But I maintain that recognising and packaging these external "services" into "components" of any description does not affect the nature of the PD-SI dependency.
Paul.
We are saying the same thing
My reply to this seems to his disappeared - doubtless my own fault, so here goes again.
If you're saying that the availability of packaged external "services" should impact the way the PD is written, then no way!
What I am saying (and this is hugely important) is that in enterprises of any size and complexity the PD is too hard a problem to solve in one bite. The notion that any application can wholly contain all the relevant parts of the PD is just not feasible except by implementing stove-pipe systems with all their attendant problems. Embedding the PD in the application is the cause of the customer in every application problem that banks continue to spend enormous amount of money to solve.
So I was specifically referring to PD services as the way to break down and distribute the PD. This is what operational customer repositories do. They implement a piece of the PD independently of the applications that use it, and each application invokes it as a service.
Also note that this thinking leads inevitably to a separation of PD from the application.
Another way of describing this is that I was reversing the conventional way of thinking about applications as the centre of things linked together by more-or-less ad hoc interfaces. And saying we can think of applications as assemblers of PD services. The PD is what is stable (and as Jeff rightly points out of value) and applications are in comparison transient and disposable.
This all ties in with my mutable versus immutable requirements distinction.
Otherwise I agree with you.
BTW, I thought you knew how much I hate being called 'uncle' except by a certain person of our mutual acquintance
The "f" word
Firstly, business domain specific objects/components can not be reused across applications for the very simple reason they contain business specific data [...] Thinking back, I'm astonished we even tried.
I was wondering who's gonna be the first to mention the "f" word?
Ok, I'll do it: frameworks. Been there, done that, bought the t-shirt.
At one point the world went mad trying to turn everything into re-usable frameworks, which never flew. Spent a lot of years and dollars for some people to figure it out though. I'm talking about business level stuff here, not technology or implementation level frameworks (which can work in specific cases but have their own drawbacks, and are easy to get wrong).
So Uncle Phil, you want to share that story on the most effective way to get to the same endpoint?
Paul ;)
Reusable business frameworks
Yep! IBM San Francisco project must have been one of the most expensive software failures in modern times. It was a huge bust!
But if you read what I said I was not advocating component reuse. I was advocating reuse of what components do, i.e. services.
In addition I did not refer to web services. I used services to mean a generic and abstract interface of some description.
phil
Web services has no impact on the pd-si dependency
I disagree with your closing comments. The fact that the nature of the SI is web services has no impact on the PD-SI separation and dependencies in the other thread you refer to. It makes no difference to the architecture Paul and I described that inside the SI we are talking MQSeries or RMI or XML-RPC or SOAP or ...
Jeff
What does "service" mean?
I suppose it all depends on the semantics of the term "service".
Most of us think of web services as SOAP and WSDL and hence it is no different from any other messaging technology. This would imply that the PD<-SI thing is unaffected.
However, some people think of web services as semantically much greater. The Portal community thinks of Portlets as "web services" - as an example. However, this example would still leave us with "web service" dependent on PD.
In the AOP (aspect oriented programming) world there is a notion of "cross-cutting" services such as security that when implemented in a SOAP environment using the SOAP Chaining Framework, could potentially create a PD->SI dependency, but only if the PD were able to call the cross-cutting services directly and I'm not sure that this is good architecture or design.
Nevertheless, the point I'm trying to make here is that the terminology is fluid. Hence, any proclamations on what is right or wrong architecturally ought to be carefully boxed in with a definition for "service" in the particular context.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Service means ...
"PD-SI separation and dependencies in the other thread"
Technical semantics appart a service is the work performed by one that serves. So what makes a one more or less dependent on a servent is how much it needs to know about the inner working of the servent + the comunication protocol that needs to be used (intefaces + language/grammars).
My point is that the degree of dependency between a PD Layer and an SI Layer can be tunned basically by the communication protocol used to establish collaborations between both. In other words it as little to do with how the PD is built or the SI is built but about how and what the servent serves + the contraints of the communication protocol.
To this one can mitigate the indiosincresies of the communication protocol through the use of translators (Facades and Proxies).
Nuno Lopes
What does "service" mean?
David wrote:
Nevertheless, the point I'm trying to make here is that the terminology is fluid. Hence, any proclamations on what is right or wrong architecturally ought to be carefully boxed in with a definition for "service" in the particular context.
Exactly!
On an entirely unrelated point, I had serious reservations about the SOAP chaining framework mechanism as implemented in Apache Axis, and which has nothing to do with FDD. So we should take offline.
Re: 'Web Services'
Its funny how several people thought I said 'web services' when I deliberately didn't use the term. I said 'services' meaning an interface independent of any possible implementation.
Otherwise see my response to Paul.
phil
SOA trumps OO on reuse
I feel that the comments left by Ramkumar Kothandaraman ( a Solutions Architect on the .NET Enterprise Architecture Team at Microsoft ) on a recent post of mine - "SOA & Persistence - Its all about Services" - may contribute to the discussion. I quote:
"I have been involved with SOA based projects for the past two years. The key abstractions that I have used successfully are
a) Business concepts such as Person and role (Note: I didn't use the word business objects).
b) Business rules that act upon facts. Business concepts are just one type of facts. There are different types of business rules such as Structural, Validation, Policy etc. They can be enforced at different layeers.
c) Business services: Services offered by your business system. Business services provide a service contract. Interaction is essentially message oriented. Request and response Message carries a 'Document'. Document may contain information about facts.
d) Business activities: These include CRUD type stuff and other computation required to satisfy business requirements.
e) Business Process: There are three types of processes namely: Human workflow, UI Process and scheduled process. Scheduled process is automated process that is composed of business activities and business rules. Human workflow also defined further notions of tasks, actors, roles etc.
I strongly believe these are the first class abstractions. One can use some OO patterns to implement any of these abstractions. But, they are secondary abstractions."
Services are indeed much more reusable than objects/components when designed as described above.
SOA >= OO ?
Services are indeed much more reusable than objects/components when designed as described above.
Aren't we simply talking about layers of abstraction here? Isn't a service just a high-level domain-oriented interface to the PD? The facade pattern enables service-oriented design (SOD??) and OOA has been using this for years.
Alas, the very term "service" is (as so much terminology in IT) ridiculously overloaded. We could be talking about services in the sense of web services (eg. SOAP), RPC services (eg. CORBA), separation of concern (SOC) services (ie. what PD exposes to HI), inter-module services (within PD), and more. Each of these is not only implemented differently, but are conceptually different. Since Phil was avoiding talking about web services specifically, I presume the discussion here is more about the services or interfaces exposed by the PD.
Since higher-levels of abstraction (whether services, interfaces or whatever) tend to reduce coupling, these approaches are more likely to be reusable. But there is nothing inherent in services per se that makes them more reusable than a well-designed component.
All too often in OOAD, people design classes as glorified "structs", where the interface is often not much more than a series of get/set methods. This trap does tend to produce data-heavy interfaces, and actually promotes coupling which then undermines encapsulation and reuse. These designs could definitely benefit from a more service-oriented perspective, even at the level of the individual class.
There seems to be a certain amount of talk that would imply SOA is something apart from OOA. But presumably an SOA application is implementated with objects, so OOA is not dead in any sense of the word. SOA seems to place more emphasis on the provision of domain-oriented services as independent from the implementation, which has to be a good thing.
As for simplifying systems, we definitely need to do more of that! Designing an OO system with a view to providing services at various levels of abstraction can certainly go a long way toward this goal.
:: Gavin Baker - http://antonym.org
Services do not affect the method of implementation
Gavin
Services are abstractions but they are than this. A service should be a large grained capability that the PD provides and I consider services to be behavior of the PD as a whole and any interaction with the PD is specifically not a service.
Services certainly impact how an application is organized (layered) but otherwise do not affect how the application is implemented.