I was listening to this podcast on the MWD blog, a podcast with Kris Horrocks from Microsoft. I find it weird given the reputation that MS has in enterprise computing, but this is the first podcast with a vendor involved in SOA which stands out.
Some points that I extracted from it:
1) Microsoft seems pretty serious about inter-operability.
2) SOA is all about managing relationships between various IT environments (this was not explicit in the podcast, but I ended up with this impression). I have the impression that the drop in the cost of telecommunications spawned the interactions between IT departments within a company as well as in different companies. (This is a minor point though).
3) I really liked the part (this was toward the end of the podcast) about having a management console which can be used for admin-ing different Microsoft products such as SQL Server or Biz Talk server. I got the impression of a management abstraction layer that gets put on top of an application so that you can plug this application into an operational environment easily. The admin tasks from Biztalk server must be different from the ones from SQL server (I’d be very surprised if Biztalk Server needs to handle roll-back segments, datafiles, etc…), but there are quite a few which are similar: transaction thru-put and a few other examples in the podcast seemed to make a lot of sense. I really liked this part, MS seems pretty serious about management. (As a side note, I would assume that they found a way to delegate management concerns that fall outside the scope of their management console to someone that could handle them.)

I get the impression that MS will actually make a pretty important contribution to SOA, and that it will be in management where it will occur. SOA could be the means thru which MS will break into enterprise computing.

A while ago I made the case for business logic aspects, arguing that in a sense AOP is similar to SOA: you basically compose together an application by weaving business logic aspects where necessary. The example I gave was that of a taxing aspect that gets applied transparently to various financial operations so that when carrying out a financial operation you also tax it.
Pretty good in theory, and I still maintain the same opinion: if you can apply business logic concerns transparently thru AOP you should probably do it.
However, when watching this interview and this interview I realized that one big piece is missing from this picture: domain aspects modeling. The person in the first interview advocates using annotations for modeling aspects, approach that I don’t think scales pretty well. Aspect modeling is very crude for the time being (it is true that we are at the beginning of the adoption period for AOP so a lot of things are not in place) and this would imply that you cannot model complex aspects and complex interactions between aspects and advised classes. Pretty much all the business logic aspects I came across in different interviews are very crude and consist of very small operations, engaging the advised class in a very limited ways.
I guess this is only how far you can go ahead today. Tomorrow will probably be different, the case for business logic aspects grows and at one point the emerging complexity will have to be managed one way or another.

P.S. From what I read I see that annotations are widely used for creating pointcuts. This approach means that basically you are creating your pointcuts in Java code and not outside of it (in an AspectJ query or Spring config files) which is, to a certain degree, contrarian. I wonder if this is not related to the fact that currently you can manage your Java codebase a lot better than your spring.xml files or your AspectJ queries.

I took a look at Yahoo Pipes and decided to write a small post about it. Don’t expect too much from it, as it is the case lately I don’t have the time to take a deep look at it.
I like the theme that Tim O’Reilly put on it in this post:
Jon expressed a vision of web sites as data sources that could be re-used, and of a new programming paradigm that took the whole internet as its platform… Using the Pipes editor, you can fetch any data source via its RSS, Atom or other XML feed, extract the data you want, combine it with data from another source, apply various built-in filters (sort, unique (with the “ue” this time:-), count, truncate, union, join, as well as user-defined filters), and apply simple programming tools like for loops. In short, it’s a good start on the Unix shell for mashups.

I concur with it, it is true: thru the use of RSS data is being exposed in a standard way and this standard is used for putting together different data sources. You could argue that RSS broke down the barriers where were separating content in different sites and that Pipes is the software which lets you combine these datasources in very imaginative ways. Pretty good. Except that I don’t think it will achieve the penetration touted by most people.
The biggest obstacle to making come true this vision of web sites as a series of datasources is the fact that Yahoo PIpes serves niche users and not breaking the barriers between various sites/datasources them. Mind you, breaking these barriers was not an easy task and keeping these barriers down relies heavily on unpaid abor (imagine what would happen to most of the Yahoo Pipes if people would stop pushing stories onto digg, book-marking items on del.icio.us, blogging about Lindsay Lohan, etc…). In a sense Yahoo Pipes lets you surf people’s past-times, but this is another story.

As I was saying, the problem is that there are way the needs to surf these datasources are very narrow. Taking a look at the numbers of times each pipe has been run would indicate that the pipes created so far are not that popular (low 5 digits are nothing today), which would indicate that they are not easily consumed. I assume that they are not easily consumed because these pipes are servicing very pointed needs, needs which are not shared by most people.
Looking at Yahoo Pipes as if it is a market you end up with the impression that it is an illiquid market: you cannot map pipe consumers to pipe producers easily. The main way of mapping pipe consumers to pipe producers is to make each pipe consumer create its own pipes by using an editor (which I must confess I have not used), the pipe consumer becomes a pipe producers and the market becomes liquid. Well, this is not happening because your average Joe will not be able to construct a meaningful Pipe, partly because it doesn’t really know where to look for content, how to filter that content efficiently and partly because it has no desire to learn how to chop-up XML (even if Yahoo claims to have made it braindead-easy).

Your average Joe needs an agent that would do that for him, that would bridge the gap between a pipe consumer and a pipe producer. Well, that agent would very likely not do it for free. So how would you put together average Joe and the agent that would service its very narrow needs? In an old post I was musing about how to service niche communities by creating mashups that would use other sites (Amazon, eBay, Google Maps and now Yahoo Pipes). An example of a Yahoo Pipe that could target a niche efficiently could be putting up a this Pipe that lets you find an apartment near parks, public libraries, produce markets, etc… You could take this pipe and put it up on a real-estate agency’s site and provide that real estate agency’s customer with something worth-while. The customer could do exactly the same thing on Yahoo Pipes, but it doesn’t know how to. Well, the real estate agency could provide this on its site and provide a better experience. The real estate agency coupled with the web-site developer that puts up pipe on the real estate agency’s site is the agent that bridges the gap between the pipe consumer and the pipe producers. I see this as a way to make the Yahoo Pipes market liquid.
Another way to make this market liquid would be create a market-place where pipe consumers would make requests for pipes along with prices and pipe producers would fulfill these requests and get paid, similar to Amazon’s MTurk. To be honest, I’m not sure if this is feasible, but it is worth noting.

Yahoo Pipes would be an interesting service. The web has been turned into a huge database where anyone with a browser can find what it needs. The revolution happened. Nobody cares.

Later Edit: In a certain way an Yahoo Pipe is a piece of code, a piece of intelectual property if you wish. Yahoo Pipes forces pipe producers to give their IP away for free (as far as I see). I wonder if this is not a barrier to adoption as well. If I make a good pipe I’d like to see some benefit coming out of it.
Another point concerning pipe creation is the large number of websites/datasources. Putting together an efficient pipe requires the pipe creator to know the data in these datasources pretty well, the barrier to pipe creation is not just chopping up data coming from different sources, but also picking up the appropriate sources for data. This is a far greater barrier to adoption as far as I see it because it shifts the effort of pipe creation from data transformation (trivial) to knowledge about data (not so trivial). My .02$

All is quiet on new years day,
A world in white gets underway.

Remote EJB Homes should be cached because in order to instantiate one you need to create a context binding to the server hosting the remote EJB home. The context creation is a pretty heavy operation (involves among other things checking security certificates, etc…) so it should be minimized. The fact that you are dealing with remote EJB Homes raises the possibility that the server hosting those homes can get restarted, etc… Your cached EJB home will be stale once this happens. This should be avoided, the cached EJB Home should be re-instantiated on such exceptions according to some fail-over policy.
A possible interesting use for AOP.

I was reading this interview with Arjen Poutsma on Spring Web Services when I came across this paragraph:
One of the newest additions is the Spring Web Services subproject, which according to the Web site “is focused on creating document-driven Web services [and] aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.”

This is pretty interesting. I am not sure if you have heard the case for contract-first WS, one argument is that the web-service is essentially an interface (since it exposes a contract to the outside world) and generating it from an EJB or a POJO (as it was the case a couple of years ago) would basically imply that you are deriving an interface (the WS) from a concrete implementation (the EJB or the POJO), which, as you probably agree, is brain-dead. Later edit: This way of relating to remoting has some OOP ideological shades: you are basically forcing OOP concepts (deriving an implementation from an interface and not vice-versa) onto something that may not need to conform to these OOP concepts (inter-system communication in this case).
However, I am not buying this 100% anymore. The reason that I am not buying this 100% is that WS is basically a remoting mechanism among a few others (REST being its main competitor)and the the emergence of different application assembly platforms (frameworks, applications, suites that let you compose an application out of components that are exposed). One popular application-assembly platform is AJAX (which I happen to believe has been hyped out of proportions). AJAX favors small envelopes and REST is probably a very good fit for it, so chances are that you will need to expose your app REST-style. But, who knows, you may need to expose it WS-style as well because one system only talks WS and it needs to talk to you so you would need to remote your app in WS as well. I would say that the fact that your application needs to talk to different systems in different ways means that remoting an application is a functionality best done transparently (I am stating the obvious). It also means that you cannot fore-see 100% the way your app will interact with other apps and the contract-first WS are probably limited to scenarios when you have complete control over the interaction between that application and the other systems (which doesn’t happen very often).

On a side note, remoting an application is essentially an exercise in communication, and the way you do remote an application reflects the various stake-holders and their degree of influence quite a lot. The use of WS is pretty much a picture of the way your organization manages its communication channels: contract-first WS would probably fit a top-down approach in which the communication between various IT assets is spec-ed out before-hand, while WS used for remoting an existing application would imply an approach in which the communication is delegated to the team supporting that application and that is responsible for how it communicates with the outside world.
Not that the 2 are mutually exclusive: you can have a contract-first WS (designed top-down by an SOA architect) piggy-back on an currently running WS which has been remoting an application for ages. Another reason why these approaches are not mutually exclusive is that they have different scopes: top-down interaction is coarse-grained (you can control only high-level issues from the ivory tower) while delegating some degree of control to the IT team supporting the application is fine-grained (they can expose finer access to the application). Depending on what you need from that application you will interact with it differently and thru different channels.
SOA is a bit about control of the IT assets and it is partly a backlash against delegating control to the IT teams. A right balance should be found between what should be managed centrally and what should be delegated and to whom.

P.S. I didn’t sleep well last night and it probably shows. Please leave a message if something is not clear (as it is probably the case).

This is the language which develops when developers/architects talk to domain experts during requirements gathering, etc… It is used for creating a common vocabulary which can be used by the rest of the team so that knowledge flows more efficiently. Pretty good, except that I find pretty limiting, I get the impression that is anchors you to a particular set of domain experts rather than getting you insight into the domain. This language is basically a boil-down of the terms that you are using with the domain expert you are talking to. Problems appear, however, when you start talking to a different set of people about the same things and you find out that they are using different expressions for them.
I am working in an environment where I interact with quite a few BUs, each of them using, you guessed it, their own language. One word can mean quite a few different things depending on who you talk to, and one thing can be expressed by quite a few different words, again, depending on who you talk to. You are constantly shifting from one meaning to another. I find it pretty cool, to be honest. I also find that deriving domain knowledge from conversations with business analysts is a very tiring exercise when compared to reading up on the domain. The first thing you should ask a domain expert is not “So how does this entity relate to this other entity?” but rather “Do you know a good book about the domain?”.

I find the Ubiquitous Language to be a very superficial way for acquiring and communicating domain knowledge. Getting trained in the domain itself by reading books is a far better proposition rather than jotting down words/expressions as you talk to a domain expert. Your conversations with domain experts will improve, this is for sure.

Later Edit: UB is not a way to acquire and communicate domain knowledge. I find that UB, like other DDD artifacts such as bounded context, serves primarily to manage concepts and limit the costs of disseminating these concepts within a group.  These costs are confusion, mistaking one concept for another, falling behind in understanding the domain and the application, etc…
I was a bit harsh when I first wrote this post…

I was reading this post on manageability.org when I came across this quote:
So banking om my own experience, the primary reason I never spent the effort to upgrade was that a lot of my data was not independent of the modules used for viewing them. The three main culprits were the Wiki system, the polls and the comments.
…
The lesson learned here is clear, never adopt a system where access to your data is tightly coupled to the code that renders it. The failure of Object Oriented Databases and Proprietary Code Repositories give ample historical lessons as why such an approach leads to failure over time. The flexibility afforded by a generically accessible data will always outweigh the benefits of structured data store access.

I never thought about this, but you can get locked into a particular piece of functionality. Functionality is usually tied to a particular business process, so you are basically locking yourself into a business process. Business process are transient and in today’s world in which change is the word of the day that particular business process will probably change in time as well. The coupling between your application and that particular business process will determine how easily it can be re-factored in order to align itself with the transformed (or new) business process. Process de-composition (emerging buzzword ;-), watch it carefully) will probably play a big role in taking care of all this. One idea is to break the process (or functionality) into blocks at various levels (from high-level to low-level) and then re-assemble these blocks so that they end up delivering the required functionality. In order to do this efficiently you need domain knowledge.