SOA Single Point of Entry Anti-Pattern

Contrary to the title of my blog post, my objective here is not to play a game of buzzword bingo or to talk in three-letter acronyms (TLAs) – although we may have some fun along the way and may even invent some new TLAs.

My objective is to introduce you to an architecture we are increasingly coming across and to set out a structured argument as to why I consider this to be an anti-pattern. If you want a definition of an anti-pattern take a look at Wikipedia.

It was during a conversation with Alistair McLeod that he termed this an “SOA Single Point of Entry Anti-Pattern” so the credit or discredit must fall at Ali’s feet 🙂

What is the “SOA Single Point of Entry Anti-Pattern”?

We are using “SOA Single Point of Entry Anti-Pattern” to describe an architecture that is built on LiveCycle Data Services (formerly known as Flex Data Services) and uses a single RPC destination – we have termed this a Single Point of Entry Architecture.

The Single-Point-of-Entry (SPoE) Architecture typically passes key-values pairs (a map) as data to the client, and requires the client to hold a security token that must be passed with each and every request.

The Single-Point-of-Entry (SPoE) Architecture fronts an internal SOA. The SPoE proxies requests to back-end services. When a client sends its request it must include the name of the back-end service to invoke. The SPoE extracts the service name from map and invokes the service.
The motivation for doing this varies and on its own makes sense. However, if we consider what we lose and what affect it has on the architecture of our Flex client does it still make sense?

I strongly believe not. If you have made the decision to build a Rich Internet Application (RIA) why would you not want to get the most out of the technology and build the application that you can? It doesn’t make sense to me to build an RIA that is constrained in the users experience that it can deliver now or in the future.

Why you should be using LiveCycle Data Services?

LiveCycle Data Services offers a robust and scalable technology for building rich user experiences. It allows the architect the choice of RPC services, messaging and data management services.

Using messaging we have the opportunity to build a real-time user experience. When a new event occurs the server can notify the client.

With data management services you can build a Data Orientated Architecture (DOA). This offers endless possibilities from collaborative user experiences to disconnected applications.  Data management services accept the responsibility for synchronising data between the client and the server and across clients. It will also fetch data-on-demand using paging and lazy loading.

What are the arguments against a SPoE Architecture?

A SPoE will impose on your client-side architecture. You will require an architecture that can compose a model from the map and decompose your model to a map. Your architecture will be:

  1. verbose
  2. un-necessarily complex
  3. difficult to debug
  4. costly to maintain

If you don’t build a strongly-typed client-side model, screen development will be harder and data binding will not be as effective. This could lead to increased development effort and more bugs.

A SPoE will increase the effort required to develop the client. Your project must asses the impact on the:

  1. budget
  2. timescales

A SPoE will not future-proof your application.  Consider the benefits of LiveCycle Data Services and the effect it will have on the user experience. You will not be able to benefit from the following:

  1. data push
  2. data synchronisation
  3. data paging
  4. lazy loading
  5. offline data synchronisation of Apollo applications

A SPoE will require you to hold a security token on the client. You will not benefit from the security features built-in to LiveCycle Data Services, which extend those offered by your underlying application server. You will need to implement security features behind the boundary for:

  1. authentication
  2. access control

To avoid using a security token we could configure a security constraint in LiveCycle Data Services for our SPoE that forces authentication. This would use the baked in functionality provided by the application server and we can identify the user via the user principal. However, we still couldn’t apply access control on the boundary nor could we execute any public services e.g. forgotten password.

A SPoE could compromise the security of your application server. By not using the security offered by LiveCycle Data Services and applying it behind the application boundary your application server will open and more susceptible to malicious attacks.

A SPoE will not benefit from the security provided by your application server. Security is baked in to most application servers and built-on by LiveCycle Data Services. If you are managing your own security token it could have an impact on:

  1. clustering
  2. fail-over
  3. scalability

 A SPoE security token could have an impact on performance. If you are creating your own token you will need to protect the user identity. Relying on SSL may not be enough – it doesn’t protect the token when it is not travelling over the wire. You should consider obfuscating the identity held in the token and have the ability to verify you issued the token and known when it has expired. All this typically involves cryptography. What impact will this have on the size of the token and the bandwidth? In addition cryptography is typically an expensive operation and will add an overhead to every single request. If you don’t apply these preventative measures you will leave your application open to:

  1. spoofing
  2. replay attacks

A SPoE security token will increase the effort on your project. If you roll-your-own security it will not be proven. Before your project goes live you will have to conduct penetration testing, which can be timely and costly. This will have an impact on your project:

  1. budget
  2. timescales

What if I have no choice?

I appreciate there are circumstances when there is no option but to use key-values pairs with back-end services. This is not unusual when building a new application on top of a legacy system and the cost of re-architecting the services is cost prohibitive.

In such cases I still advocate using LiveCycle Data Services in the manner it was intended. You can still surface multiple services to your Flex client and you can still use messaging and data management services.

I would encourage you to build an abstraction layer behind your LiveCycle Data Services. The problem of composing and decomposing your model doesn’t go away it is just pushed further down your architecture. However, it will probably be easier to build in Java, keeping your client side architecture clean and, more importantly it won’t compromise security.

5 Responses to SOA Single Point of Entry Anti-Pattern

  1. Peter says:

    What if I would prefer my server to be independent of any specific rich client (so I could reuse the backend services with e.g. a Silverlight client)?It seems you are advocating a tightly coupled architecture which in a lot of environments is not the best (strategic) choice and which others in other situations might also rightfully classify as an anti-pattern.The fact that one is building a rich internet app is really not related to the choice of client/server communication technology to use.Choosing a loosely coupled architecture that is not coupled to any specific proprietary communication technology is *not* an anti-pattern.At least as far as I can see, it does not classify as”Anti-patterns, also called pitfalls, are classes of commonly-reinvented bad solutions to problems”Peter

  2. Peter Martin says:

    Hi Peter,You raise an interesting point. I don’t believe there is any reason why your server can’t be independent of any rich-client. It is a case of thinking about how you architect your back-end services, which is the aim of my blog post.However, at some point we need to publish our services so they can be consumed by the rich client. In the world of Flex this is best served by LiveCycle Data Services, which can wrapper your back-end services so they can be used by Flex. I am sure this is the same with Silverlight or any other competing RIA technology. Regardless of which technology use a SPoE is not a good service layer.This does not mean I am advocating a tightly coupled architecture but one that recognises the benefits of RIA’s. As stated in my blog post if you choose to take a different route you will have a lot of additional work to do in your rich client, which I believe should be avoided.CheersPeter.

  3. Peter says:

    I guess I got confused by the fact that the post seems to mix an architectural pattern with its implementation with a given product.Would it be fair to say that there is nothing specific in LDS that makes it more or less suitable in avoiding SPoE than e.g. using an HTTPService based REST approach?Depending on your tooling I understand that the communication without LDS might require more “home grown” code (the 10K/CPU does buy you something 😉 ) but there is nothing preventing one from avoiding SPoE without LDS….at least that is what I would be tempted to think.In other words the fact that one falls into the SPoE trap is orthogonal to the technology being used.Peter

  4. b100dian says:

    > To avoid using a security token we could configure a security constraint in LiveCycle Data ServicesI totally agree with the article (and am totally against ‘SPoE Architecture’, but I have a problem with Flex Data Services that manages that “security token” thing thorugh *cookies*.How could we even consider having the state on the client if the server needs cookies? (that is, two clients in the same browser are in the same server-side state)

  5. sharp aquos says:

    Choosing a loosely coupled architecture that is not coupled to any specific proprietary communication technology is *not* an anti-pattern.