Service Integration at the Presentation Layer

Wilfred Springer

How did we end up here?

Fifteen years ago, at the end of the two-tier client server age, people started to realize the importance of distinguishing between at least three different layers in the architecture. A business layer, providing a convenient API allowing you to address a particular business concern, a data layer storing related data, and a presentation layer providing a convenient user dialog on top of the business logic.

Three layers

At some point, it became apparent that modularizing like this was not going to cut it. We needed to modularize the business tier and create 'services' addressing particular concerns. This is what we ended up having:

first-split

In our new world, we did have services with clear interfaces, and these services communicated through each other through clearly defined interfaces (either local or remote). However, we were cheating. In most cases we couldn't figure out how to preserve consistency without relying on the convenience provided by SQL solutions, so we allowed for some 'integration' at the data layer; that is, we stored all data in a single database, and essentially faked isolated services on top of that. And then - since we still needed to be able to present a single integrated user interface - we created a single presentation layer component that pulled in everything it needed from the business logic below.

The rise of SOA essentially caused us to focus on service boundaries even more. And although we had different schools of thought - and there were actually quite a few folks who felt like service oriented had nothing to do with web services - the focus started to shift from a modularization problem to a remote integration problem. So it was essentially about pulling the different things already identified even further apart.

soa

Now, if you pull services apart like illustrated above, the link to a single data store is obviously going to hurt. So a good thing about everything that happened back then is that everybody started to feel the pain of linking to a shared data store. The technical complications forced people into making services have their own data layer, and drop 'integration' on a data tier.  It might not have been the ideal reason for doing it, but the net effect was this:

more-isolation

This is when people also started to realize that ACID wasn't going to cut it in the long run, and we should consider other was to preserve consistency, paving the way for NoSQL and spreading the word on compensating transactions and idempotence.

So what do we have now? On the plus side, we do have services that are pretty much isolated from each other (good!). However, the integration with the UI is still pretty much one big blob. And for some reason, that is considered quite ok. But is it really? In many cases, the dependencies between the presentation layer and the business logic layer are pretty tight.

Let's take a payment service as an example. Whatever the payment service will require from the user to enter, obviously needs to be entered in the presentation layer. Replacing one payment service with another type of payment service will most likely have big implications on the presentation layer. At the same time, the rest of the dialog offered to the user probably is completely independent of the dialog presented when dealing with the payment service.

So, if we feel strongly that services should be isolated from each other as much as possible (free interpretation of Parnas) and keep what needs to be exposed to an absolute minimum, why not cut the presentation layer apart as well?

even-more-isolation

Presentation layer service integration

For some reason, the idea of presentation layer based integration doesn't land very well in a world once dominated by the WS-flavor of SOA. However, mashups are omnipresent on the Internet. It's just often not considered as a way to do integration of services within a single system in a single organization.

Organizing your service oriented architecture as outlined above bares some resemblance to the ideas expressed by Allen Holub more than a decade ago, but then applied on a larger scale. The central message in his article was to prevent objects from exposing too much of their own internal state by making objects responsible for providing a UI representation of themselves. That sounds like a horrible idea according to the model that promotes strict separation between presentation layer and business logic layer, but I think it makes perfect sense in a service oriented architecture.

Back to the payment service example: let's assume for a minute that the left-hand service is a shopping service (including the presentation layer dialog with the user) and that the right-hand service is the payment service. Integrating the services would require some integration on the presentation layer as well as the business logic layer.

When the user selects a payment method associated to a particular payment service, the payment service's presentation layer should be pulled up, passing clues on what to do after the payment succeeded or failed. From that point on, the payment service itself is in control of (part of) the dialog.

When the payment is cleared, the payment presentation layer will hand back control to the shopping service's presentation layer. However, the business logic layer might communicate more information on the status of a payment through the SPI defined by the shopping service. (Like settlement related information.)

conflict

Consequences

By considering the presentation layer to be part of the actual service, you introduce a couple of new degrees of freedom. First of all, depending on how the integration in the presentation tier is done, you might have the option to have part of the user dialog executing in the same address space as the business logic. Instead of having to do several remote calls for pulling together all data to be presented to the user, the presentation layer would do all of these calls internally and then ship the resulting presentation to the place where it will get integrated with the other presentation part components. It could give you the option to enjoy the benefits of spatial locality.

Another benefit that was already mentioned before is the fact that you can easily rip and replace a service. You only have to worry about the presentation and business logic layer interfaces, not about what's actually happening behind those interfaces. Think Field Replaceable Units (FRUs) but then software.

Counter arguments

The counter argument for presentation tier integration is that you would basically have to redo the presentation layer interfaces for every new type of presentation you are targeting. I tend to disagree, and since this is just a blog post, I'm going to try to walk away from it by just asking for some proof of that first.

Implementation

In "Understanding UI Integration" from 2007, the authors provide an overview of the UI integration state of the union. They basically talk about browser plugin components, mashups, portlets and WSRP (which would be one of the ways to achieve the spatial locality benefits outlined above). However, they state this:

"Although the efforts we've described here are certainly useful, we believe that effective standardization similar to that of standardizing service interfaces is needed for UI integration to really take off. In general we see a lack of abstraction to conceptualize composition-oriented features in the context of UI integration."

I think that still holds today. There might be a few initiatives to push boundaries a little further (OpenSocial comes to mind), but there is no clear direction.

So what is your opinion on this? Do you consider services having a presentation layer interface malpractice or critical to true service oriented architectures? And if you do have services offering a presentation layer interface, what principles do you have in place to keep it all organized?

Comments (8)

  1. Srirangan - Reply

    July 21, 2010 at 3:56 pm

    Interesting post, and very cool images. What did you use to make them?

  2. [...] This post was mentioned on Twitter by Xebia BV and Christophe Heubès, Oliver Schönherr. Oliver Schönherr said: Enterprise mashup pattern http://bit.ly/b0XSmu "Service Integration at the Presentation Layer" [...]

  3. Andrew Phillips - Reply

    July 21, 2010 at 10:49 pm

    "First of all [...] you might have the option to have part of the user dialog executing in the same address space as the business logic. Instead of having to do several remote calls for pulling together all data to be presented to the user, the presentation layer would do all of these calls internally and then ship the resulting presentation to the place where it will get integrated with the other presentation part components."

    Ironically enough, this is fairly close to what we had in the days of fairly static (Web 1.0-ey) server-generated sites. One of the main lessons from that time appears to have been that these types of interfaces don't deliver the kind of dynamic, responsive user experiences people have come to expect.
    Hence more complex UIs1 with more (presentation) logic and a tendency to make more calls to the backend.

    "The counter argument for presentation tier integration is that you would basically have to redo the presentation layer interfaces for every new type of presentation you are targeting."

    Not quite sure I understand that point - do you mean that you would have to change the presentation logic every time the service was used in a different context, e.g. on a mobile device vs. in a browser? That might be so, but with a "monolithic" presentation layer you'd also have to figure out how to re-display this service.

    Having said that, I think there are at least two reasons why "self-rendering services" are problematic. The first is that it would require every development team to include UI specialists. That might sound like a feeble argument, but from my experience it's still far more common to see layer-oriented development teams, with the "server-siders" working here and "the UI team" working there.2

    More importantly, I have difficulty seeing how one could ensure a smooth, homogeneous user experience if all components render themselves. Whilst at in the business layer you can always squeeze in another adapter to bridge between two services - heck, most companies have huge platforms3 that do nothing else - humans don't work that way. You can't install a "translation" layer between the ugly widget and the user's eye or brain4.

    Even with strict corporate guidelines you very quickly end up with confusing interfaces, differences in convention and odd patterns of interaction - as most enterprise portals demonstrate. And if it's external services that are rendering themselves, even corporate guidelines may not get you very far.

    Are there really many UI experiences more ugly, annoying and confusing than the wretched MasterCard SecureCode/Verified by Visa thing?

    1. Not necessarily more complex for the developer to write, but you won't easily convince me that all the JavaScript churned out by GWT results in a simple UI
    2. The increasing adoption of Agile is of course also resulting in a moving towards more multi-disciplinary teams, but personally I'm not convinced by that. Lessons from many other branches of science and engineering show that having a few specialists all over the place is inferior to having many of them in centres of excellence. But that's a different story...
    3. ESBs or other home-grown message buses
    4. OK, yes, of course you could, but that rather takes us out of the sphere of enterprise development, I'd say
  4. Wilfred Springer - Reply

    July 22, 2010 at 7:53 am

    Ironically enough, this is fairly close to what we had in the days of fairly static (Web 1.0-ey) server-generated sites. One of the main lessons from that time appears to have been that these types of interfaces don’t deliver the kind of dynamic, responsive user experiences people have come to expect.
    Hence more complex UIs1 with more (presentation) logic and a tendency to make more calls to the backend.

    If anywhere in my post you got the impression that I am opposed to less-than-straightforward and highly dynamic UIs, then I should correct that. I am not advocating dropping everything we ever learned about highly dynamic and interactive UIs. I am just saying that all of the complexity of building that highly interactive user representation of the service should be considered the realm of the service, rather than something you slam on top of the service requiring the business logic layer to expose more than it should.

    If that means that there is a server side counterpart of the presentation layer that is servicing requests from the client side presentation layer to build that highly dynamic service, only that client side presentation layer of the service gets to see the server side presentation layer services. And that server side presentation layer could reside close (same box, same address space) to the business logic layer part of the service.

    If you integrate the presentation layer on the client, then the client should only see the outer surface of the presentation layer; so, just the interface of something allowing a piece of the dialog to run in a certain context. Same on the server. If you decide to integrate the presentation layers on the server, than you might use portlet technology, but the portlet itself is part of the service. If you use Wicket, then the you only now that you have a Panel belonging to the service that you can instantiate in a certain context. However, the context in which you instantiate that component does not need to know what's going on inside. All communication between that Panel and the business logic layer it is built on is private to the service.

  5. Wilfred Springer - Reply

    July 22, 2010 at 8:09 am

    More importantly, I have difficulty seeing how one could ensure a smooth, homogeneous user experience if all components render themselves.

    Couple of remarks on this one.

    • Note that I have been talking mostly about the adoption of these principles within the enterprise, within a single a company. In that case, there is always (hopefully) an acceptance test of the entire solution. I don't see why the approach outlined would prevent feedback from acceptance tests being worked into a friendlier and homogeneous user experience. But perhaps I'm just too optimistic on that.
    • Another way of guaranteeing a smooth and homogeneous user experience is 1) to put some guidelines in place, and 2) to make sure that the presentation focuses mainly on what it needs to get across to the user, rather than how it will be rendered. CSS comes to mind, but also XForms type of solutions, allowing you to tell a story about a dialog with the user, rather than talking about the way its going to be rendered. Wicket is similar, in a way. The dialog is completely defined by the Page and Panel components. The HTML pages define how it should be rendered.
  6. Wilfred Springer - Reply

    July 22, 2010 at 9:09 am

    Whilst at in the business layer you can always squeeze in another adapter to bridge between two services – heck, most companies have huge platforms3 that do nothing else – humans don’t work that way. You can’t install a “translation” layer between the ugly widget and the user’s eye or brain4.

    Well, perhaps you can. Let's jus that this is the situation:

    In this case the integration breaks both at the business logic layer and the presentation layer. It might be broken on interface definitions, or on soft integration problems. (Like, it works, but it looks awful.) Typically, this happens with off-the-shelf services you try to integrate. Especially in absence of any real standards for UI layer integration, it doesn't always result in optimal user experience.

    In cases like these, adapting the business logic layer interface is well-understood. Adapting the presentation layer might be possible (if it's just a few simple changes, then perhaps you can get away with a simple transformation), but if it's not, then you might still build an alternative presentation layer that you can build on top of the upper interfaces of the business logic layer of that service.

    The net result would still have similar properties as building that entire stack from scratch: you would still be able to integrate it with the presentation layer of other services without having to worry about what's going on inside.

    integration-conflict-solved

  7. gvandieijen - Reply

    July 24, 2010 at 9:39 pm

    To continue on the example, what would you do with something like th stock service - the service used to manage the stock of items? A presentation layer for the stock service wouldn't be very reusable.
    The stock service would be used in various parts of your presentation layer: for example in the catalog (so the user can see how many products are in stock) and during checkout process (to decrease stock once the product is ordered).
    (now would be nice to insert a good diagram, unfortunately I don't know how to insert graphics in comments).

    Of course you'd create extra (one-use only) services like the catalog service and checkout service, which in turn use other services. In most cases, that would just complicate design without adding anything: in the business layer those services would contain little logic, as most logic and development effort would still be in the presentation layer.

    A better way for to improve design and re-usability of the presentation layer would be to identify and create reusable components. To be able to reuse them, you'd first have to agree on a common standard to create those components: Like JSF, Wicket, GWT or Flex.
    Then you can start thinking of reusable components, based on your backlog. In case of a shop, you could think of a product view component, a catalog component, shopping cart component, a menu component or authentication component.
    Some components could use a service of the business layer, and some components could use other components.
    Unlike services, the components would be stored in a central repository, like a maven repository. Since components are copied, upgrades of the framework used (like going from Wicket 1.3 to Wicket 1.4, or Richfaces 2.1 to 2.2) shouldn't hurt existing installed (web)applications.

    A while a go I found an article which goes more deeply into the above: http://www.developer.com/design/article.php/10925_3751486_1/Front-End-Architecture-Where-Business-Meets-IT.htm
    Slightly other terms are used: frontend and integration instead of presentation and business, portal and interface instead of component and service although there meaning seems to be the same.

  8. Andrew Phillips - Reply

    July 26, 2010 at 9:52 am

    If anywhere in my post you got the impression that I am opposed to less-than-straightforward and highly dynamic UIs, then I should correct that.

    No, no, it definitely wasn't my intention to imply that. My comment was based on the initial assumption that you'd most likely end up with server-side UI composition (à la JSP). Thinking it over, that conclusion was probably "tainted" by a vision of dumping the responsibility of adding a UI on a backend service development team.

    Another way of guaranteeing a smooth and homogeneous user experience is 1) to put some guidelines in place, and 2) to make sure that the presentation focuses mainly on what it needs to get across to the user, rather than how it will be rendered.

    Fair point, and indeed skinability was one of the main solutions/mitigations to the issues I raised that I had in mind1. But there are certain things that are hard to skin, e.g. whether you model a date selector as three day, month, year boxes or a date picker widget.
    That feels like a very low-level example, but then again getting the UX right often tends to depend on such seemingly trivial things.

    ...if you start doing this for a couple of services aren't you back to building your own UI on the basis of server-side interfaces? At this point, I should add that I'm definitely in favour of a) not allowing UI helper methods2 in the external service interfaces and b) keeping the responsibility of display within the service - from a modularity and reusability perspective that's where it should be.
    In that context, Gerbrand's comment raises an interesting point:

    A better way for to improve design and re-usability of the presentation layer would be to identify and create reusable components. To be able to reuse them, you’d first have to agree on a common standard to create those components: Like JSF, Wicket, GWT or Flex.

    I'd be interested if you could clarified which level of abstraction you're thinking of when you talk about services rendering themselves. Is it technology-specific widgets such as Gerbrand is referring to? Is it a "view-specific" API that exposes UI-required data e.g. via REST. Is it a fully rendered page/frame that can be displayed in a browser?

    1. And which I conveniently failed to mention for tactical reasons ;-).
    2. OK, let's be realistic: too many UI helper methods

Add a Comment