I’ve began rethinking certain assumptions about how I use message passing in my distributed systems after reading things like “SBA & EDA Lessons Learned” from the excellent “Panic from Fuzzy” blog. Since I was only familiar with the Tuple Space theory but have never employed space technologies like JavaSpaces, I did the only thing I could do – I convened a session on it at the Software Architecture Workshop so as to benefit from the knowledge and experience of those frightfully smart guys.
 The functional issue that attracted me to spaces was its ability to do very dynamic like content-based filtering. By subscribing to notifications based on a template, I could replace a broad and deep topic hierarchy and handle some other interesting scenarios as well. For instance, when a given user is working on a certain set of data – a tree of specific instances, I would like that machine to only get updates on that data, which could be quite a substantial savings in terms of network load. Another case is where the user is only allowed to see certain instances of the same type.
 

About three quarters of the way through the session, when I was still thinking that I could put entities in the space, someone called my attention to the fact that I would have to give up the cross-entity transactional semantics that I was so used to. For instance, in order to implement a business rule when an order is cancelled the customer may also need to be updated to a non-preferred status. This calls for a transactional scope around both of these updates – on the business level. If the entities were in the space, the naïve solution would be to Take the order, change its status to cancelled, Put it back in the space, Take the customer, updates its status, and Put it back in the space. By not being able to perform all this work transactionally, failure cases would need to be handled by compensating transactions – a significant jump in complexity.
 Needless to say I left that session quite a bit cooler on Space-Based Architectures than I was going in, but later on in the day, over a beer with one of the guys, he suggested that maybe spaces could be used as an alternative way to do message passing. Instead of Taking and Putting entities, we could do the same for messages – since the business-type of transactions would by-and-large correlate to a single message. We could benefit from the dynamic subscription behavior and possibly do away with a deep, and sometimes fragile, topic hierarchy. Once again my enamourment was on the rise.
 

But as do all fickle loves, this too was not destined to last. After doing some more thinking I remembered about handling failure cases in terms of message passing. When dealing with reliable messages, the receipt of a message, its handling, and the subsequent sending of new messages is at times required to be all transactional. I was once again required to perform a Take operation as well as multiple Put operations in a single transaction.
 I hardly believe that this is the end of the story for me and spaces. I’m still getting my head around using spaces as a technology choice in my current architectures and examining new architectural possibilities around it as well. We are definitely living in interesting times.

Update

After reading “What about Usability”, Jeremy’s latest installment of his “Better Software Development” series (my words, not his) I got flooded with a bunch of thoughts. Mostly things that I’ve wanted to blog about before but didn’t. So please pardon the disjointed nature of the following notes.
 

Since I’m writing this while on the plane to the Software Architecture Workshop in Switzerland, I’m reminded of a discussion I had with Arjen Poutsma at this same workshop last year. I think that the original topic had to do with Web Services, but it meandered around quite a bit. I think it started by me saying that services should not expose CRUD style operations. Arjen countered by mentioning that most user interfaces in line-of-business applications exposed the same model to the user by having them fill out data in grids. My retort to that was that while humans can get used to almost anything as long as its consistent, that doesn’t mean that it is a good solution. In the systems that I work on there is usually an HCI (human-computer interaction) person on the project who designs the UI, mostly around the tasks they perform. These tasks often corresponded very well to the coarse-grained messages we employed in terms of SOA. We finally agreed that the successor of SOA would be TOA (Task-Oriented Architecture) in its aggregation of client-side aspects to the already server-centric principles of SOA.
 

A different topic that came up in a recent meeting in one of the projects I’m consulting was how long users expect to wait for a response from the system. What made the HCI person rethink his design was my suggestion that certain algorithms could be deployed client-side and since their performance for the kinds of work the user would do most of the time was on the order of a couple of hundered millis, we could run them “interactively” – as in, on every mouse-click. This input eventually brought about a greatly simplified and much more interactive experience for these expert users. I’m no HCI expert, but I’ve learned a thing or two over the years, and one of the important ones was the need for synergy between architecture and HCI design.
 

Finally, code that supports highly interactive user interfaces is non-trivial to say the least. Jeremy brought this point up and suggested using design patterns like MVP with a healthy dose of unit tests. I couldn’t agree more, well, yes I could. Even if you use the next generation patterns of Passive View and Supervising Controller, the Dependency Injection development style, and the Command Object pattern, it will not be enough! I’m seeing, in real time, what happens to a project that utilizes all the appropriate patterns, manage their dependencies well, decouple fervently with events, and keep their code clean at all times but doesn’t require/encourage developers to write unit tests. It is a stability nightmare. If you have a complex system to build with intricate logic as to what can be activated when, or any long list of detailed requirements in terms of user interaction, ignore unit tests at your peril. Having a testable design is a great first step, but if you don’t go and test, you’ve negated quite a lot of its benefits.
 

I hope that that didn’t amount to just a bunch of over-tired, jet-lagged, incoherent babbling, but I’ve been waiting to get it off my chest and now seemed like just the time to do so.

More information:

Usability is Timeless, and things that are still broken with usability today.

Get it here.

[Salt and Pepper, Peanut Butter and Jelly, Toast and Vegemite (if your down under) – these are all things that go together. But what goes with SOA you ask? Why Workflow of course! On this episode we are joined by Microsoft Archtiect MVP Udi Dahan who gives us his insight into putting these two technologies together.]

I just can’t seem to shut up about these things. It’s gotten so bad that I’ll be inflicting the same session I gave in TechEd Developers Europe on our local Israeli crowd at the end of this month. You can find out what other horrors Microsoft has in store here.

Clatoro’s NetBlog points to a survey showing that “Typical SOA Development Takes 3-6 Months”. First of all, statistics can be doctored to show whatever you want. Second, seeing as the definition of what exactly constitutes SOA is unclear (is WS-* in or out?) the value in comparing that to your current SOA effort is questionable. Finally, does that development include testing, deployment, support, etc, or is this just pie-in-the-sky coding?

Bottom line, don’t believe it for one second. Just getting a handle on the coupling between the applications and systems in your enterprise can take a couple of years. It’s worth it, but don’t kid yourself – it takes time.

Late one night over drinks at TechEd Developers in Barcelona, discussion among the Israeli delegation (Noam King, Alon Fleiss, Yosi Taguri, and myself) turned to SOA. I swear I didn’t force them into it. Anyway, after some debate over what does and does not constitute a service (we all agreed that functions that accept or return XML over HTTP do not), Alon proposed his own definition.

“A service is software hosted on a service host that gives value or functionality that can not be part of the client software. The client & service has to partly understand each other to get the value.”

I understand where Alon is coming from but every definition I’ve ever heard for a service, or SOA for that matter, seems to focus on the service pretty much in isolation from other services. One of the main challenges I encounter when designing large-scale systems is what services there should be, what they should each be responsible for, and how they should interact. I have yet to see a definition that helps me out in that respect. I focus a lot more on inter-service interaction than client-service interaction. And it’s not that I don’t get involved in the architecture and design of client-side software, I feel that it is absolutely necessary to get hard problems like threading right before we get started.

I’ve written a lot about inter-service interaction already so I’ll just give a short summary of my thoughts here. Asynchronous, message-based communication with the common case being publish/subscribe has been much more successful in my experience than synchronous request/response. Furthermore, when ACID transactions are kept entirely in the scope of a single service, I have found that those services are often responsible for a coherent fracture of the business domain.

The problem with client-service interaction occurs when viewing the client as something other than a service. If the client is not a service by design, then that would make it part of a different service, and thus more tightly coupled and not required to use the above-mentioned communication patterns. The purpose of a “client-service” is to enable the user to send commands to, and receive notifications from the services with which he interacts.

It is probably for this reason that I have a hard time analyzing examples like that given in Alon’s post. I don’t think that it’s possible to reach valid conclusions about the division of responsibilities in a domain without having the entire context. Web services like those exposed by Amazon and Google are, in my opinion, components exposed over HTTP using XML and SOAP. In order to judge their validity, we’d need to focus on the use of those components in a larger solution.

It looks like we’ll never be able to reach an agreement on these topics due to the kinds of problems each of us face in our projects, and the kinds of solutions we attribute to the term SOA. The truth, as always, is somewhere in the middle.

Yesterday I got an email from one of my enterprise architecture friends asking me what I thought about the relationship between SOA and EDA. He explained that this question was rooted in article he read on the subject positioning SOA firmly out of the EA space. After reading the article in question I remained firm in my belief that SOA is EDA and that the way many describe SOA is little more than synchronous RPC over Web Services – no Architecture to speak of.

The main thing that I was enthusiastic about in the article was the case made for architecture-level business-focused events. This is very much in line with the successes I have had in implementing this architectural style. The asynchronous messaging patterns of old that have proven their robustness and scalability are at the heart of SOA and EDA. Publish-subscribe semantics between services brings about services that contain all the data they need, structured optimally for their processes. Designing services this way does, in fact, bring about a high level of autonomy where the unavailability of a single service won’t bring about the failure of others.

However, one statement that Jack van Hoof, the author, makes about transactions has been a disaster in my experience. Jack states:

“If atomic transactions cross the decoupling borders, then implement compensating rollback transactions at these points.”

In every project where I have encountered a design requiring atomic transactions crossing service boundaries, that part has been problematic at best. In those cases where the business absolutely requires atomic transactions across certain parts of a business process, it is prudent to co-locate them in a single service. Trying to patch things together across services with compensating transactions has led to complex and buggy code in all services involved, high coupling between those services, and poor performance. When compensating transactions can be defined at the business level, only then do so in your services. Examples of this include the cancelling of a vacation involving hotels, airlines, and rental cars. Even though the cancelling of the rental car may fail, the hotel and airline cancellations should remain – this is defined at the business level. Therefore, the use of multiple services with compensating transactions between them is justified in this case.

There are some nice visualizations of these concepts in the article which may be useful in explaining them to business stakeholders, but technically contain some inaccuracies. For instance, the flow of data in an EDA is portrayed as: Source – publishes to an event – subscribes to a target (source-pub-event-sub-target). What actually occurs in an SOA/EDA is based on two separate flows. First, the “target” subscribes to the event. At some later time, when the “source” publishes the event, the information about the event is dispatched to the “target”.

It is important to understand that “source” and “target” are roles that each service can take at any time, in fact, a service can take the role of source for one event and target for another at the same time – it is all dynamic.

All in all, I don’t think that EDA extends SOA, but rather that the concept of SOA has been abused up to the point that it is loosing all coherence. I think that it is ineffective to employ web services within the boundary of a service. The decision to tightly couple elements within a service occurs at the business level. Introducing technical loose-coupling with web services inside that boundary will lead to more costly and poorer performing solutions. Atomic transactions within the boundary of a service will create high technical coupling despite the use of web services. It is important to match the technologies and techniques we use to the areas of the solution in which we use them, or pay the penalty in terms of costs and performance.

After telling all this to my enterprise architecture buddy, he asked me: “Why can’t you guys just settle on one term already?” I answered, “like it’s any better in the enterprise architecture space with your TOGAF, DODAF, and Zachman”. May we all continue to live in interesting times.

The other day I ran into a blog post titled “Master Data Management – just another load of inaccurate data?” and got this feeling of deja-vu. This idea of having a single location where the authoritative definition of an entity lived is not new. Enterprises have been going back and forth on the continuum of centralization-distribution for years. The whole SOA and BPM fads that have taken the world of IT by storm appear to have stirred up this topic yet again, this time incarnated as “Entity Services”.

For those of us who went down the path of centralization, and failed, I probably won’t be bringing any words of wisdom. But for those who haven’t, maybe this warning will save you some grief – I only wish I knew where to look back when I was doing this.

In the example shown in the blog post, the problems that occur when customer data is duplicated in multiple back-end systems are discussed, as are those of employee data. The source of my failure rested in the belief that there is such a thing as a coherent entity. Only later did I find out that for sales different data was important than for billing. It was not so much the issue of data that got us in trouble, we just created a super structure for all the data, but that the business rules were so different – at times appearing inconsistent and contradictory. We finally had to ditch the centralization effort – there were too many worlds colliding that couldn’t be reconciled. Entity services appear to be directing us down that same logical, yet misleading path.

The author quotes some popular beliefs about SOA that appear to make matters worse:

“The problem is that I don’t see how MDM helps SOA. SOA needs to work with disparate backend systems largely intact, benefiting from the logic they already provide. It should not be trying to replicate or rebuild the business logic in underlying systems, since if you are going to do that you might as well rip and replace those systems, not duplicate the logic in the integration layer.”

This view of SOA being bound to reuse at the expense of quality and effectiveness is misguided. Proponents of SOA tout reuse as a benefit that will occur in the future, but never is reuse introduced as a constraint in designing an appropriate architecture. This view of SOA is understandable given the EAI history so many bestow up SOA. Personally, I do not view SOA as an integration technique. Rather, I look to the principles of SOA to help in finding the inherent fracture points in the business domain so that services can be designed to handle each section of the domain. Services designed in such a way will be as loosely coupled as is possible.

I would suggest that we as an industry focus more on learning from lessons of the past than jumping on the latest bandwagon and betting the future of our projects and companies on unproven, vendor-driven acronyms. Maybe then, we’ll be able to codify those lessons in such a way that we’ll have repeatable successes worthy of acronyms.

Here’s another question I received quite some time ago that has some food for thought in it. Wes asks:

“I’ve built up a service framework in which various service definitions (capabilities) are exposed as web services which are connected via a service bus. I have two public interfaces that communicate with the service bus, an asp.net 2.0 web application and a api web service that business partners use for service access and system integration. All capabilities and both public interfaces talk to the service bus via a service bus proxy. I currently have two service bus proxies … one internal and one external. The difference between the internal and external proxies are the internal one exposes all methods of all capabilities and the public proxy only exposes methods that do not require service orchestration (coordinating calls between various capabilities). Currently this means that the public interfaces are “forced” to go through a workflow in order to do certain things, whereas internally, the workflow capability can call any method of any capability. The goal is to try and reduce the number of “wrong things” that a client could do and to reduce the burden of the client to know which order to call things in and having to implement compensating logic when errors occur.

Any advice, experiences, or resources are most appreciated.”

Like I said, lots to digest. I don’t think that I understood his scenario entirely, but I think that the following bit of advice is quite pertinent:

In my opinion, the service bus should not have different APIs. The bus I use has 3 main methods:

Send(IMessage msg);
Reply(IMessage msg);
Publish(IMessage msg);

The specific messages that are sent are defined by what the service provided to its consumers. If a service wishes to expose only certain messages to a set of consumers, all it has to do is give them the appropriate subset of messages. The consumers won’t know what other messages they can send, so chances are they won’t send anything else. If security is a requirement, then you’d have to check, in your service, where the message came from before handling it, so that if someone shouldn’t have known they can send you message X, but they still did, your service will reject the message.

Always a pleasure, Nick Malik’s Inside Architecture blog hits another one out of the park. Declared, Visible, and Open Coupling gives me exactly the kind of meaty examples I like to sink my teeth into. The fact that I disagree with Nick’s solution makes this even more interesting, since I usually do a lot of head-nodding when I read his stuff.

What are the services Nick proposes?

So, what kind of service is “create co-op partner”? First off, it is a composite service. It needs to orchestrate between two lower-level services. For the sake of argument, I’ll call the lower level services “partner-master” and “add-to-co-op-master”.

These are examples of services that embody the anti-pattern I identified “services as the interface to a business process”. My recent podcast episode gives some more background on this.

What services would I have? Well, by analyzing this “workflow” description:

“If I send data to a service that creates a co-op partner, and I don’t know the id in the partner master system, then I need to look the partner up, and if they are not found, create them in the partner master system, then take their partner id and add them to the co-op system. I may not want to do any of that if they are not eligible to join the co-op system.”

I’d have PartnerMaster and Co-op services – incidentally corresponding to systems already there. PartnerMaster would publish (either periodically, or as a result of some change, either to all subscribers, or just to the initiator) the list of partners. Co-op would subscribe to that, and thus know everything it needs to know about partners.

The workflow above would not be encapsulated by an external service. The request to create a co-op would go to the Co-op service, which would check the eligibility of the application. Seeing that the Co-op service knows all about what partners exist, and that it is already coupled to the PartnerMaster service (subscribing to its notifications), I would have the Co-op service handle this workflow. Send the PartnerMaster the CreatePartner request, save the state of the workflow, receive a response, re-hydrate the workflow and pass the response to it, and based on the result, either create the co-op or not, finally sending a response message to the initiator of the create co-op request.

What we see in this solution is no added coupling between our business-grained services to handle the requirement. No “composite services” either. In which case, we don’t need any “declared coupling”.

This is such a great example for showing the different solution styles, what might be called SO style and SOA style, that I’m considering adding it to my TechEd presentation: ARC307 Adding Value to Message-based SOAs with Workflow.

Well, only if you do it wrong.

From the Sound Advice entry:

“Services should be objects with lots of methods and represent effectively a whole application.”

Umm, no. Consider a more “document-centric” approach. The only kind of object I could consider comparing a service to would be the Active Object Pattern, and that falls horribly short.

“SOA seems to be fundamentially about a message bus.”

Well, if that’s what it seems to you, I can’t argue the point. But, if we take the “seems” out of the equation, it would be much more accurate to say that an effective SOA implementation might use a message bus of some kind.

“…SOA has no equvalent concept. Instead, it concentrates on the transfer of arbitrary messages belonging to arbitrary protocols. It promotes the idea that object-orientation and RPC with their arbitrary methods on arbitrary objects with arbitrary parmeter lists are a suitable means of addressing the communications issue.”

No, it does NOT “[promote] the idea that object-orientation and RPC with their arbitrary methods on arbitrary objects with arbitrary parmeter lists are a suitable means of addressing the communications issue”. Exactly the opposite.

Sorry, Benjamin, but I think that proving REST is “better” than SOA by distorting the main principles of SOA isn’t helping. If you like REST, use it. The grass may not be greener on the other side, but let each tend to their own garden.