Archive for May, 2005
05.20.05
Posted in Presentations at 5:15 pm by kkj
Yesterday I had the good fortune to give a presentation on Aspect-Oriented Programming (AOP) using Aspect/J at TietoEnator, Copenhagen. The target audience was senior developers, and the slides therefore focus on technical aspects of AOP, and Aspect/J syntax. Following the presentation we had a good discussion on when to use AOP and what it probably isn’t great for.
In short, Aspect-Oriented Programming is a discipline, which addresses modeling cross-cutting aspects of object-oriented code in a modular fashion. These are things like logging, profiling, billing, security-checks, exception handling, and the like, which are strewn across packages and traverse inheritance-hierarchies. This is, at least, the general perception of AOP. Where it gets tricky and debatable is when AOP is used for systems development, business logic and the like. Adrian Coyler’s blog on AOP with Aspect/J has a set of interesting entries on this topic.
Sun for one doesn’t like it although JavaOne will host a panel discussion this year on AOP. The teaser says it all:
“Aspect-Oriented Programming (AOP) technology is receiving a great deal of attention within the object-oriented programming community. Although it provides a great deal of power, it also potentially greatly disrupts program semantics. This session hosts a lively debate between some leading proponents and some leading doubters of AOP.”
The Sun strategy is to provide frameworks, and employ design patterns to model cross-cutting. In J2EE for instance you have Servlet Filters that can intercept calls to URLs matched by some pattern. There is no similar mechanism for EJBs although it would be natural since the application-server already intercepts all calls in its EJB-container and uses similar techniques to provide security, transaction control etc. to bean implementations. Had there been a filter facility for EJBs, and a way to piggy-back context information on RMI calls, I probably wouldn’t have gotten started on AOP in the first place. Take that, Sun ;-).
In my mind, AOP is yet another tool in the architect’s toolbox, highly suitable for certain purposes. I have used AOP with success to hide complexities, avoid annoying frameworks, and enforce coding style. But just as you wouldn’t light a cigarette with a flamethrower, you shouldn’t base enterprise systems entirely off AOP.
In short: Like all the other tools our there, AOP is no magic Silver Bullet.
Permalink
05.13.05
Posted in Architecture at 12:34 pm by kkj
Most of the literature out there on Service-Oriented Architectures (SOA) addresses the issue at a level of abstraction, which implies that the author has not spent a day’s honest work in actually applying principles to practical problems. For those of us who are faced with the challenge of not only talking the talk … this is rather frustrating.
In short what you can read out there is that SOA is a design principle for distributed systems, which governs the way peers expose functionality, connect, and interoperate. A SOA is composed of services, which are exposed by its peers, and that good, well-behaved services follow certain design principles.
- Stateless - The service does not keep any state on behalf of the callee. This implies that all needed input is delivered in one shot and leads to the next principle.
- Coarse-grained - Services deliver coarse-grained functionality. A service is typically not a simple getter or setter, but rather a high-level function.
- Loosely coupled - Tight coupling makes versioning difficult tying the communicating peers so strongly that a change in one easily means a change in the other.
- Well-defined - The interface of a service is well-defined, and ideally also immutable.
What you cannot read is what happens when you try to apply SOA principles to an organizational context as well as an inter-organizational context. At least, I haven’t found a decent treatment of the topic, so here’s a first shot.
SOA inside an organization
The IT infrastructure of a large organization, which has been around for some time and accumulated a bunch of legacy systems often has at least the following characteristics:
- Islands of functionality - The IT infrastructure is composed of systems, some of which work independently, are not connected to common repositories, and which contain redundant information. Examples include local databases, ERP systems, specialized tools, even spread sheets.
- Not service oriented - Depending on the system, it may be able to expose data or functionality through well-defined protocols, but this is often not the case. To integrate, you may have to write to files in proprietary formats, pump SQL through ODBC connections, open sockets and the like. And if you are really unlucky, the legacy system is sealed tight, integration-proof.
- Heterogeneous - Systems were built over a stretch of time on different platforms, in different programming languages by different companies.
- Not supportable - Once upon a time there was a programming language called COBOL. Unfortunately most of those who knew it are no longer among us, and the COBOL source for the system is only available on some obscure storage media for which there are no longer any functional drives …
- Centralized Control - The IT department is typically in charge of running all the systems and hence it is easier to introduce supporting components like an Enterprise Services Bus (ESB) to the system.
SOA across organizations
When the organizational SOA needs to talk to the rest of the world or expose business services, it takes on the logical role of a single system. Just like the organizational SOA is composed of systems internal to the business, the inter-organizational SOA is composed of services external to the business. You may say that the inter-organizational SOA can be composed of organizational SOAs. The term business refers in this context to a company, an organizational unit or any entity with its own set of systems that can expose functionality.
The inter-organizational SOA is very different from the organizational one:
- Service-Oriented - Most likely the services that are exposed to other businesses were provided with service-orientation in mind.
- Homogenous - Web Services more often than not provide the plumbing for this kind of SOA and businesses are standardizing on this technology.
- Supportable - If services can be published, chances are each organization is also capable of publishing new services, or alter existing ones (based on some contract).
- Decentralized control - Businesses are autonomous entities that require contracts to cooperate. While one organization in such a SOA may take on the role as registry, service-police, etc. it is much more cumbersome to establish this inter-organizational infrastructure than it is for a local IT department to make decisions for all systems in the organizational SOA.
Conclusion
It seems to me that in order to qualify the discussion on Service-Oriented Architectures we need to extract lessons learned from applying this design principle to various distributed systems. What we will learn from going through the exercise within an existing organization, connecting legacy systems is very different from what we can do in an external SOA, built with Service-Orientation in mind. One interesting topic, which I’ll pursue shortly is the role of the Enterprise Services Bus within the two SOA types and the challenges in applying such a beast.
Permalink
05.01.05
Posted in General Ramblings, J2EE at 12:08 am by kkj
Years ago when I was first introduced to object-oriented analysis and design, the lingua franca at my university was Coad/Yourdon. A relatively simple approach to modeling, this language is mainly concerned with identifying classes, attributes, interactions, and operations of a domain model. Since then, Coad/Yourdon, Booch, OMT, Rumbaugh and all the others have gone the way of all good things and been replaced by that one single unifying modeling language, UML.
In itself, UML is merely a notation and does not mandate any specific design and analysis process. That said, of course, the diagrams do dictate the concepts and structures said process must use, such as classes, objects, relations, actors, and the like. In other words, this is a modeling language for object-oriented analysis and design processes - or at least that is the general perception.
Yet, if you give it some thought, there is nothing inherently object-oriented about defining requirements through use cases. In fact, it may be argued that use cases model functional behaviour and could equally well be used for other paradigms, functional, procedural, logical, and the like. Use cases are first and foremost a tool for communicating systems requirements between end-users and system-developers whether you choose to diagram them using UML or not. The Use Case diagram adds structure and makes it easier to get a quick overview (a picture is worth a 1000 words), but there is an inherent danger in the formalism introduced by these diagrams as well. Blinded by the beauty of formalism, the untrained analyst may well embark upon a functional decomposition spree that renders the use cases overly detailed and unreadable, forgetting the main goal of these constructs: communication. When defined appropriately, use cases capture system requirements at a high level and lend method to implementation and testing.
In the J2EE world, a common pattern for modeling system functionality is the Session Facade from Sun Microsystem’s Blueprints Catalog. With this pattern, system functionality is modeled as business components through EJBs and exposed to clients as coarse grained Stateless or Stateful Session Beans. The latter, it is explained, could be used in the case where a client needs to perform multiple steps, and state needs to be stored in between.
The Blueprints catalog claims to be based off experience and best practices, and in reality these show that Stateful Session Beans don’t scale very well (see for example Bitter EJB by Bruce Tate), which defeats the very purpose of EJBs in the first place, viz. providing a mechanism for distributed transactions in a highly scalable and available fashion. Whoever came up with these beasts certainly also didn’t foresee the advent of Service Oriented Architectures (SOA), where services are coarse-grained, stateless, loosely-coupled and have a well-defined interface. (see fx. Mark Colan’s treatment of the topic)
So given that we cannot store any transient state on the server side, and need to implement business processes modeled through use cases how do we proceed? Again we can fall prey to the temptation of going into extreme formalism on the use cases and implement a state machine for each one of them. While this can be done, the work needed in going from a communication model (the use case) to an implementation-ready one (the formalized use case) is quite likely overkill for most applications. In any case such a state machine has to be on the client-side for reasons discussed earlier and here a less formal approach might as well do. For each use case we could implement a (set of) controller classes for maintaining the state and performing communication with the server side session facades. Of course the client would employ the usual J2EE design patterns, Business Delegate and Service Locator for decoupling and performance reasons. The Model View Control pattern might serve as an inspiration for interactions between the user interface and the server side.
Permalink
View Kåre Kjelstrøm's profile
