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.