Quantcast
Channel: Oracle Blogs | Oracle The Shorten Spot (@theshortenspot) Blog
Viewing all articles
Browse latest Browse all 311

Product vs Solution vs Infrastructure

$
0
0

One of the most common questions I get from partners is support for features that are typically in the infrastructure. The main issue here is that some partners confuse what is in the product and what is in the infrastructure and the implementation solution. Let me explain.

The Oracle Utilities Application Framework based products are applications housed within J2EE infrastructure (such as Oracle WebLogic and in some cases IBM WebSphere) and for batch, housed in a runtime version of Oracle Coherence.

Now there is a degree of separation between the product and the infrastructure. Each has distinct roles and those roles are only duplicated across what we call touchpoints between the product and the infrastructure. Another complication comes into play is the role of the solution which the particular configuration of the product and the infrastructure to suit a particular need.

When I was considering writing this article to highlight the differences in product, infrastructure and solutions I bounced around a few ways of describing it but I found the nest way is in the form of a common example.

Lets use the example of security authentication (aka who are you?). This is essentially the feature of securing and identifying the user when connecting to the product. The most common example of this is known as challenge and response (or more commonly userid and password).

In terms of the roles security authentication is described as follows in terms of product, infrastructure and solution:

  • The product does not store userid and password itself. It does not make sense in the context of an enterprise application as typically security is enterprise wide, for efficiency reasons, not just for a particular product. This is delegated to the J2EE container (Oracle WebLogic/IBM WebSphere) to authenticate the user. The product relies on the container to pass or fail an authentication attempt.
  • The J2EE container, which is part of the infrastructure, supports various security repositories and standards via security connectors. For example, if you have a corporate security server that holds users and passwords then you can connect it via LDAP to the container to now implement a common identity store. The J2EE container supports a wide range of adapters and in the case of Oracle WebLogic you can implement multiples for different parts of your business. An example of this is where you can separate administration accounts from common users using different identity stores.
  • A solution for the product is a distinct configuration of the J2EE container with appropriately configured security connectors. This can also mean that you externalize this function even further by implementing an Identity Management solution such as Oracle Identity Management Suite.

As you see in the example, there are distinct differences between the product, solution and infrastructure. You can apply the same logic to a wide range of implementation aspects needed to be considered.

Now, lets focus on a particular issue using the example above. Where should the users be able to change their password?

  • The product does not have inbuilt password change functionality. This is because in a solution context, it makes no sense. This is why we do not supply one. It does not mean you cannot add this functionality to the menu as a common function.
  • The product is always connected to a security repository via the J2EE container (even the default one shipped with the J2EE container). The password change function is at the infrastructure level not the product level.
  • Typically you can change passwords from external sources which is much more logical. Lets take the common example of reusing the same security repository for LAN login and the product (via a common LDAP source with or without SSO). If you use this example, typically the LAN login allows you to change your password which would apply to all connected applications. It makes no sense in this example to also duplicate the functionality in the product. Also why would you let the product change a security repository.

The above example brings the discussion into sharp focus.

Now, how do I deal with these situations? I call it "What would product <blank> do in this situation?", where <blank> is your favorite desktop application. I usually use Office as an example (not a great example but something most people understand). You would not expect Word or its equivalent to have a password maintenance function. No, it does not make sense. Word in this example, uses the features of the operating system to do all sorts of functions like printing, scanning etc... The application does not have all these functions inbuilt (otherwise it would not be a word processor really).

Hope this clarifies the situation.


Viewing all articles
Browse latest Browse all 311

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>