Archive for the ‘SOA’ Category

Two Perspectives on HATEOAS


HATEOAS or “Hypermedia As The Engine Of Application State” is one of the core principles of REST and it essentially boils down to having links in the representations of your resources.  How to apply this principle in the design of a service and the benefits that it provides depend on the nature of the service [...]

No Comments

Why All SOAs Need ESBs


I’ve recently asked one of my developers to research some integration and middleware technologies for a project we’re working on. After spending a couple days on this, he said to me “these things are all part of ESBs now”. I.e. all the integration and middleware vendors have pretty much taken these capabilities and bundled them [...]

(4) Comments

Service Reuse


The more I think about the phrase “service reuse” or any other variation of it, the more I don’t like it. I feel like it’s making me think about services from a perspective that is too technical and too low-level. Reuse is something you want to achieve with code but you shouldn’t be thinking about [...]

(1) Comment

Extending Reuse to the Last Mile


While services make it easier to share your data and functionality, some developer still has to write the code to consume your service and present the results to the end user. In many cases, that code to consume and present a visualization of the service can be reused by other applications. This has already exploded [...]

No Comments

Don’t Go Cheap With the Service Interfaces


Vendors need to realize that in this day and age service interfaces for their products should be a core feature. Unfortunately many vendors view them as secondary requirements and thus don’t invest the necessary resources into their development. Often they are built in as an afterthought and usually by some junior developer on the team. [...]

No Comments

SOA Message Exchage Patterns


There are a variety message exchange patterns that can be used to implement an SOA. Know them and when to apply them. It can mean the difference between an SOA that scales and performs vs. one that doesn’t. The traditional synchronous request/response may not always be the most appropriate in all scenarios. Here are some [...]

No Comments

Barriers to Agility Differ Across Organizations


A lot of folks talk describe the main benefit of SOA is the increased agility that it brings to the organization; mainly describing the architectural and technical approaches and mechanisms that bring about increased agility. The problem with that is that the barriers to agility at many different organizations are not technical in nature. Take [...]

No Comments

Two Most Common SOA Mistakes


Two of the most common mistakes I’ve seen by inexperienced people trying to implement SOA are trying to make everything a service and building a huge data model and trying to force everyone to use it. First of all, not every capability needs to or should be exposed as a service. There are overhead and [...]

No Comments

More on EA, DODAF and SOA


In a previous post, I talked about how EA can be used to influence SOA to provide the strategic perspective. Here are some more thoughts along those lines, with some guidance on service-oriented analysis using DODAF views. I mentioned that SOA should be aligned to the organization’s strategic objectives and that EA can help drive [...]

No Comments

Red Herring: DODAF vs. SOA


Those of you who work with the DoD are probably very familiar with DODAF and lately have probably heard a lot about how DODAF is incompatible/inadequate for representing Service Oriented Architectures. While there may be some truth to that, I consider it to be somewhat of a red herring. DODAF is primarily used to create [...]

No Comments