Who is an Architect

This may not be a new discussion for many, but I am writing this out of recent observations when people of all walks of IT think themselves doing some kind of architectural work. Every computer programmer, system designer, IT support director, computer operator, PC owner, data architect, database architect, network architect, business analyst, systems analyst, enterprise architect, service architect, object architect, project manager calls whatever they do or want to do or maybe, whatever, they are doing as, “Architecture?" It is chaos. As John Zachman puts it, "This is killing Enterprise Architecture…". So what is Enterprise architecture from an IT perspective?

          Enterprise Architecture when defined from an information and technology perspective explicitly describes an organization through a set of independent, non-redundant artifacts, defining how these artifacts interrelate with each other, and developing a set of prioritized, aligned initiatives and road maps to understand the organization, communicate this understanding to stakeholders, and move the organization forward to its desired state.

        From a Business perspective, Enterprise Architecture illuminates how an organization and all of its members can achieve its objectives, through the creation of a series of engineered models and project initiatives, that can be easily understood by all of the people associated with the organization.

       If an individuals contribution is to just about talk on these artifacts (or even worse BS on those) and not work towards creating them, please stop calling yourself an Enterprise Architect. May be they can be called as "Art Vandelay" Architect as in one of SeinField's episode.

Websphere JNDI resource scoping

Most folks have their application deployed at cluster level and so the resources attached to them such as Database, JMS, etc., I was challenged by my websphere administrator the need to create database resources at cluster level when applications created at different clusters talk to same database. My initial hunch was these resources are isolated under cluster and therefore will not have resource contention, however when they are moved to cell level their isolation is lost and resources will now be shared by all application clusters.

Interestingly this wasn't true. Even though IBM marks resources created at cell level with broader scope, when it comes to connections each node gets its own share. Despite the scope of a defined resource, the resource properties apply at an individual server level only.The application scope has precedence over all the scopes.

• The server scope has precedence over the node and cell scopes.
• The node scope has precedence over the cell scope.

For example, if you define the scope of a data source at the cell level, all the users in that cell can look up and use that data source, which is unique within that cell. However, resource property settings are local to each server in the cell. For example, if you define the maximum connections as 10, then each server in that cell can have 10 connections.

The cell scope is the most general scope and does not override any other scope. The recommendation is that you generally specify a more specific scope than the cell scope. When you define a resource at a more specific scope, you provide greater isolation for the resource. When you define a resource at a more general scope, you provide less isolation. Greater exposure to cross-application conflicts occur for a resource that you define at a more general scope.

MDB controller

Message driven beans and other resource adapters based on JCA technology have lifecycle stages that can be controlled for precise timing of when a message is to be read from queue or when a file need to be read from a location. Prior to EJB 2.1, MDB's were just message listeners based on listener ports and could read messages only from JMS queues. With subsequent revisions they were based on JCA connector architecture which provided flexibility to have MDB's to not just listen JMS queues but also file systems, ofcourse proper listener need to be implemented. In addition, JMX extensions on these components provide non-intrusive way to control the lifecycle of JCA, which is Initialize, passivate and activate.
I came across a requirement to fetch messages dropped into the queue only at defined intervals and not just when message was available. Websphere JMX AdminService API exposes provides operations that can interrogate available J2CMessage bindings and issue commands to either pause, resume the endpoint listeners. One caveat though is these activation specs need to be initialized within your application for AdminService to look them up. In other words, if you have multiple EAR's encapsulated with MDB's and if you wish to control them centrally through another EAR (all deployed on same cell), you will not be able to passivate without them being activated first.

String endPointlistener = "*:*,type=J2CMessageEndpoint";

javax.management.ObjectName queryName =
new javax.management.ObjectName( endPointlistener);

AdminService adminService = AdminServiceFactory.getAdminService();
Set s = adminService.queryNames(queryName, null);
Iterator it = s.iterator();
List mbeans = new ArrayList();
while (it.hasNext()) {
ObjectName mBean = (ObjectName) it.next();
result = adminService.invoke(mBean, operationName, params,
signature);
}

Dynamic JCA Connection Factory Substitution

JCA connection factories can be categorized logically into two sections. One that manages connection details and other interaction details. In websphere (and I presume the same with other application servers) you have to configure connection details on these factories as part administrative action. I had a requirement where connection host was fixed but authentication information for the host was different based on scenarios. Unless there was a way to dynamically substitute security information you would end up creating multiple connection factories.

In websphere you can set custom properties using the prefix "CP" to your resource property within your application. Ofcourse this will involve using IBM specific API within your application code to lookup connection factory and dynamically substituting connection details. Most of JCA Connection properties can be set using this approach except the hostname.

For example, to you may have a Connection factory marked against a file resource adapter, with JNDI com/eis/myFileCF dedicated for I/O write operations. Supposing, there are many folders that are operated by certain users who have privilige to delete while others have only write access it may become a daunting task to create dedicated connection factories to isolate these set of users. Instead application developers can lookup the connection factory by JNDI and inject any property variances such as username and password, in this case, like
                 conn.setProperty("CPuserName", "user");
                 conn.setProperty("CPpassword", "{xor}49dksdldk");

   Note, the password is masked using xor alogrithm. Websphere encodes J2C credentials while saving into file system and later decodes when sending them out to appropriate endpoints; your dynamic injection should encode the same way for proper processing.