Any day now…

Thank you so much for your insightful comments.

It’s great to see that you agree on the point that business objects should NOT be elevated to the stature of a service.

To your question about product price information – that is something that would be published by some “business component” in the marketing service. If part of a system needed that information, it would subscribe to those messages.

Hope that clarifies things.

It’s actually OK for an Entity service to represent more than 1 “Business Entity” (or Business Object), as long as their relationship represents a know business concept (perhaps several granular business objects only really have meaning in a business context when thought about together). Maintaining conceptual integrity is key when deriving the concepts to be represented by Entity services; the goal is not to work from the database-up as your boundaries, but from sound business concepts irrespective of storage – a common pitfall when developing Entity Services, because it’s so easy (and often viable) to “webify” business object methods.

One of the most important things in an SOA (or any architecture) – vital to maintenance, governance, and discovery – is the concept of ownership. Ownership of product info is unclear in your scenario (w/out your comments). Where do I go to find out the price of a product? “Sales” service seems the closest match, but doesn’t seem appropriate (i.e., this svc should only be concerned with how a product is sold). Price info may seem granular (a subjective term anyway), but it does represent a DUBF (”Discrete Unit of Business Functionality” – not an official term!); i.e., it is autonomous and useful in and of itself – and a natural fit in a “Products” service. A “Products” service maintains “1 version of the truth” about product info; your example seems to scatter product info “versions” among unrelated services.

Maybe my concept of Entity Services differs from those originally espoused by MS and earlier SOA adopters; I too have been wrestling with autonomy, abstraction, separation of concerns (SoC), coupling, reuse, composition (all the concepts that contradict each other!) – even from the days of trying to make my objects more autonomous. Again I believe your ideas on asynchronous communication are the way it should be; this and pub-sub/event-driven communication architectures I believe do open the door for the business flexibility, composition, and SoC afforded by Entity services. HTTP is a naturally connectionless, stateless comm channel anyway; I cringe when thinking of all the plumbing necessary to make Web Services look synchronous over this channel; then you have scalability issues, HTTP time-outs – yuck.

Anyway, the other point in your article I don’t necessarily agree with is business unit organization as a guide for service organization. Business units (Sales, Marketing, etc.) are organized for reasons that may or may not have to do with how services should be organized – especially when you consider that business capabilities (advertised to external companies for example) may span (hence should be at a different conceptual level than) internal business units. And if you think about it, exposing services along these lines is a form of “breaking encapsulation” to external participants, as it divulges internal organization, and shouldn’t matter to anyone looking for core functionality (which bring us back to why Entity services can be so effective). Business unit organization – even internally – could be fleeting; what remain are the core “Entities” if you will, that businesses organize around and share; that’s the more relevant, flexible abstraction. Entity Svcs “make sense” internally and externally (again, if conceived right).

Sorry, didn’t mean to take up your whole blog there(!), but wanted to give as much info as I could in case I couldn’t get back into it. I’d like to know what you think…

SOA IS application architecture (what else would it be for?). Actually guys like Erl and Krafzig say that Entity (or “Basic” as Krafzig calls them) Services are the foundation for an SOA; they say an SOA must start with them, but doesn’t have to include the other service types (process, utility, etc.).

I think perhaps there’s a misconception about Entity Services; they execute disctrete units of business functionality (DUBFs) like any other service (if designed correctly). Not all services need complex process negotiation or orchestration; core business functionality is what an Entity Svc exposes, which can be useful (if desinged correctly) in and of itself. Entity Services are not an excuse to stand up CRUD or other granular operations that would normally belong in an object, but if you look at some of the methods of an Entity Object – they CAN stand alone as DUBFs.

Service composition/reuse is the Holy Grail of SO (otherwise, what’s it for?); Entity Services provide that. Once we move beyond the infancy of SO – and still beyond the notion of OO/n-tier thinking to where svcs are the FUDs (Functional Units of Decomposition) – just as with objects – there can be no meaningful collaboration without some dependencies (”nil coupling”). You want to reduce coupling of course, but as with anything you break up into pieces, you introduce coupling of some kind when you do, and “export coupling” is OK. In your world, no services talk to each other? That doesn’t bode well for the evolution of SOA, or any other technology that 1st comes in flat until the novelty wares off, then becomes taxonomized, categorized, etc. (for agility/adaptability benefits of specialization/seprartion of concerns).

The advent of Process/Activity Services help elevate that coupling to another level so that Entities can be composed without the physical dependency, but Entity Svcs can be just as autonomous as any other services – even more so by making them business PROCESS-agnostic/using Process Svcs. An Entity Svc shouldn’t care HOW it’s composed, only that it WILL be conmposed, thereby increasing the focus on the standardization (and thus autonomy) of the contract and service itself. Autonomy is served, but that is only 1 of many svc design principles – the rest of which, I believe Entity Services also adhere to 1 way or another.

Why can’t services implement the domain model pattern? It’s a pattern, and therefore not restricted to a specific technology or implementation. Entity services should be thought of as core business functionality liberators, not Entity/Business Objects or db front-ends.

Businesses offer certain information and services; Entity Services are the vehicle that exposes this info – not fine-grained if you can help it, but that’s a “Chunky-vs-Chatty” issue, not 1 of appropriate DUBF granularity (a subjective term). Useful is useful. We also have to consider that services are not just there to facilitate B2C, but B2B, or machine-to-machine communication; a well-known, standard XML schema associated w/ an Entity Svc is the perfect vehicle to facilitate this – and DOES NOT give up details that the consumer isn’t already expecting/knows about (sorry for the caps, but no italics capability!).

I hear what you’re saying, but a DUBF is a DUBF – to whomever it is useful – at any level of cinsumption. I think we have to clear up the Entity Svc misconceptions 1st though.