Niklas | 
Tags: 
02 6th, 2008| 
On of my former colleagues, Martin Rydman, has started blogging. In one of his first posts, he takes a look at Jim Webber’s debunking of ESBs. Martin is a really clever guy and responsible for the Baseline concept (or should that be “methodology”?) so his blog will be interesting to follow. But the most interesting trend here is that Zystems wants to be more open and active in the community. I most certainly applaud that. Let’s get the discussions flowing.
Feb
3
The quote on lacking SOA talents making SOA fail has been going around the last couple of days. Joe Gregorio finally nails it:
There just has to be a reason for the failure, and it couldn’t possibly be the technology. This is what I call the “Scooby-Doo” phase of the technology rejection curve, where the rubber mask has been ripped off and the crook yells as he’s dragged off by the cops:And I would have gotten away with it too, if it weren’t for those meddling kids.
Jan
22
Half a year ago, I got a copy of a presentation from a former colleague. It was from the then recent Open Group conference and was presented by Bert Hooyman of MphasiS. It covers the risks involved in running your company through the now (too) common SOA initative. The presentation, to me, reflects well on some of the limits you will run into as you implement your SOA strategy. It also suggests that an event driven architecture would be a better fit for your enterprise wide integration needs. Again, something I would tend to agree with. As The Open Group doesn’t seem to publish the presentations (so much for Open I guess), I asked Bert if he could. And he very graciously did so. Go read it, it’s well worth the time.
(This post has been sitting as a draft for quite some time, sorry about the latency):
Update: looks like there is a problem with the MpasiS site, probably temporary
Nov
22
“SOA projects tend to attract two things: Taj Mahal architects and parasitic vendors. (My words, not Jim’s.) The combined efforts of these two groups results in monumentally expensive edifices that don’t deliver value. Worse still, these efforts consume work and attention that could go to building services aligned with the real business processes, not some idealized vision of what the processes ought to be”
Jim Webber interpreted by Michael Nygard. Couldn’t have said it better myself (no really, I couldn’t). I just reviewed a customer document that in so many ways reflect on this very reality. So much that it’s saddening.
Now, I might not agree with the implementation choices made by Jim (that would be SOAP all over) but I find that his Guerrilla SOA in many ways fit with my current thinking around how to approach integration. Go watch his presentation from QCon and Øredev. Everything up to slide 18 is bang on target.
Btw, make sure you read Michaels book, Release It! It should be taught in schools.
Technorati Tags: soa
Jun
5
Bill de hóra seems to be nailing them these days.
"SOA seems to encourage business to meddle in IT at the wrong levels and might actually prevent commoditization by making all this stuff specific to a business at-a-point-in-time; like encouraging Service Oriented Electricity instead of electrical Grids and uniform access to outlets.”
On the service-oriented-architecture list.
The fact that quotes like this makes me giggle probably says a lot about me having spent to much time thinking and talking on these topics lately.
May
31
As a follow-up to yesterdays post.
"I’ve set my bozo bit for WS and SOA types who are repositioning themselves as REST stalwarts. Spotting a bandwagons is not an indicator of competence."
Aug
16
Andrew Ferrier draws up an interesting distinction between business and, what he calls, technical logic.
- Technical logic: Stuff we don’t want to do, but need to in order for everything to work.
- Business logic: Stuff we do want to do - the reason we’re doing all this. We can not only decide on how to implement this (as we can with technical logic), we can also decide not to implement it all, or to implement different logic.
As someone who spends his days recommending clients not to put business logic in the integration layer, a simple definition like this one is quite handy. And while this definition might not be complete, it’s good enough for initial discussions.
Jan
12
Service oriented architecture has been notoriously hard for the industry to define. Everyone and there dog seems to have thier own opinion. In here I collect some of the attempts. If you have further references that I should add, feel free to add a comment.
In Service-Oriented Architecture autonomous, loosely-coupled and coarse-grained services with well-defined interfaces provide business functionality and can be discovered and accessed through a supportive infrastructure. This allows internal and external system integration as well as the flexible reuse of application logic through the composition of services.
In Service-Oriented Architecture autonomous, loosely-coupled and coarse-grained services with well-defined interfaces provide business functionality and can be discovered and accessed through a supportive infrastructure. This allows internal and external system integration as well as the flexible reuse of application logic through the composition of services to support an end-to-end business process.
In short, SOA is about loosely coupled systems, message based communication and business process orchestration. As an abstract architectural model, it acts as an indirection between the business and the technology model. Web Services are the preferred implementation technology for loosely coupled and inter-operable systems.
Service-Oriented Architecture (SOA) is a component model that inter-relates an application’s different functional units, called services, through well-defined interfaces and contracts between these services. The interface is defined in a neutral manner that should be independent of the hardware platform, the operating system, and the programming language in which the service is implemented. This allows services, built on a variety of such systems, to interact with each other in a uniform and universal manner.
The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface.
A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components (services) that can be reused and combined to address changing business priorities.
Service Oriented Architecture Compass, via service-orientated-architecture@yahoogroups.com
A software architecture of services, policies, practices and frameworks in which components can be reused and repurposed rapidly in order to achieve shared and new functionality. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
SOA is an architectural paradigm whose goal is to achieve loose coupling among interacting software applications. Applications invoke a series of discrete services in order to perform a certain task. A service is a unit of work done by a service provider to achieve desired end results for a service consumer.
(Service-Oriented Architecture) Formerly called a “distributed objects” architecture, the SOA term was coined at the turn of the century as Web services were evolving. CORBA and DCOM are examples of earlier SOAs. See CORBA, DCOM and Web services.
The SOA abstracts and exposes business functions as services that connect multiple business applications in homogeneous or heterogeneous environments.
Aug
14
A new project, Synapse, has been proposed for Apache incubation. The project aims to build an ESB/broker that will complement the Apache WS stack. The main initiators of the proposal are some of the Apache WS heavyweights like Dims. While I still need some convincing of whether “the principles of service oriented architectures” is the final solution to integration, the proposal is interesting. If the project is successful (and I have no doubts it will) it will be a strong contender in the quickly evolving ESB/BPM/JBI space. It sure will be interesting to see how it will stand up against the giants, primarily IBM’s WBI and BEA’s AquaLogic. History has shown that open-source software can be very successful in the middleware space. Since that has made app servers commondity, this area has lately attracted a lot of interest from the vendors as a way of building added value on their existing infrastructure. One can not help but wondering how long that will last.
I must say that I’m a but surprised that the ServiceMix people doesn’t seem to be involved in this. It does seem to fit them like a glove, maybe some more people-level integration is needed?
Update: seems like the ServiceMix are joining in
Jul
3
As usual, Sean McGrath says it best. I agree that WS-* has gotten our of hand and it’s time to save the pieces that actually adds something.
