On 23/04/2008, Rob Eamon <[EMAIL PROTECTED]> wrote: > > > > > > > --- In service-orientated-architecture@yahoogroups.com, "Steve Jones" > <[EMAIL PROTECTED]> wrote: > > > > On 22/04/2008, Rob Eamon <[EMAIL PROTECTED]> wrote: > > > > > > I understand where the phrase comes from. The objection is to the > > > notion that tools typically associated with EAI are inherently > > > bad. > > > > inherently no, but limited and defined for a specific task which > > became highly commoditised in the early 00s. The models of these > > products are often not suited to building the sorts of > > infrastructures that businesses need today. > > Need? I respectfully disagree. The crowd I run with might be out of > touch, but virtually every client I've worked with (not very many) in > the last few years responds with a "what's that" look when I mention > service orientation. Many businesses get along just fine without SO.
Whereas, for a fairly obvious reason, the ones I work with are looking at SO to dig them out of their current problems, most often due to a legacy EAI problem. The thing about SO when looked at from the business side is that it matches much better to the value networks (collaborative business) stuff that has been coming out of business schools since the late 90s, so while people are still going "WTF is SO" I'd argue that they are facing challenges because their IT estate thinking is disconnected from their business model thinking. > > > My issue is that they haven't changed the > > model (which isn't suited to todays market) but are claiming to have > > evolved by lobbing on WS-*. > > Suited to today's market? That's seems to be a fairly anecdotal > rationale. Pretty anecdotal, but backed by lots of anecdotes :) To quote one CIO who are worked with about 3 years ago "Why would I buy X just because they've put in Web Services when we decided it was rubbish 12 months ago". My argument on EAI tools is that their basis is fundamentally an IT centric one, transforming information from and to multiple formats and doing complex processing in the middleware. This model meant that the middleware became a business application in its own right and therefore ceased to become an enabler because it was now providing not "simply" support but had evolved to be a sprawling business application. NB I'm not saying that lots of SOA "pureplays" haven't created suites that result in the same problem, but the EAI folks haven't changed the model that led to those problems. > > > EAI isn't inherently bad, but using an EAI model to do SOA is liable > > to lead to tears. > > I respect your opinion but logos would be more convincing than pathos > for me. > > Can you identify capabilities/uses of typical integration tools > (MQSI, TIBCO, webMethods, etc.) that go against the SO grain? Can you > elaborate on your definition of the "EAI model?" MQSI.... ahh I loathe it well :) Okay, MQSI is fundamentally a broker which is designed to pass messages from A to B and to do that routing based on the content of the message. This means its basic principles are around individual message receptions and a series of processing pipelines for different message types. There is no Service Orientation in its model at all. Lobbing on Web Services doesn't change the fact that MQSI likes doing pipelines by message type or queue. (NB I did actually build an SO solution with MQSI and MQSeries MA0C in around 2002-2003 but the service interfaces were at the on-ramp/off-ramp level not done by MQSI or MQSeries which we just treated as a pub/sub broker). TIBCO BusinessWorks is a BPM tool that bears an amazing similarity in conceptual model to the product that was around pre 2002. Its a process and orchestration tool which still appears to be very message/queue and process oriented in its outlook. I'm not sure where the "SO" part of the BusinessWorks model is. My point is that while they can be used successfully their basic models owe more to the thinking of process engines and MOM than they do to SO. > > The typical capabilities of integration tools seem to match up quite > well with the needs of service interactions. Even tools that don't > provide a WS interface could fit within an SO environment. Agreed, and as I said above I've done it. But it was done _despite_ the conceptual model of the product not because the conceptual model of the product helped in being SO. > > If I appear to be defending EAI, I'm not. I avoid the term "EAI" even > more than I avoid the term "SOA." :) I prefer "integration." > > > My simple world is the stuff in the book and the method. The > > architecture (which IMO are the pictures that define the solution) > > was completely based around services, the implementation teams were > > organised around services and there was a clear separation between > > the service teams using formalised contracts (in the case of the > > MQSeries this was described in CSV as one end was a choice of > > several old mainframes). > > > > My simplistic definition of SOA is that if you can't show me the > > pictures that describe the services and then point at the solution > > and show me the services as they are in the pictures then you > > aren't doing SOA. NB this is why the RM works, because it > > provides the framework context not implementation specifics. > > Going back to the York Minster example, does that mean that one would > need to show me the blueprints first before being able to point to > the structure and say "that's an example of Gothic architecture?" Nope because the Minster is a physical construct, its "picture" is itself. Because software is an abstract thing then you need the picture and the mapping. > > If the implementation of an SO solution doesn't have observable > characteristics, then why go through the whole modelling exercise? I'm always more interested in if the _operation_ of the solution is SO. The implementation being SO is certainly good to have but its the operation that will really determine the long term viability of the solution as SO. Put it this way, if York Minster was maintained by a complete heathen who operated it as just a tourist attraction rather than a Gothic Cathedral then when the roof would have burnt down they would have put a rollercoaster in. The operation of something being SO is the final proof of whether its really SO. The pictures says that it should be, the mapping says that it is, the operation says that it will be in future. > > I agree that the models are important. They define and guide what is > to be built. But after we've built what we're going to build, > shouldn't it be somewhat obvious what we have? Hence the operation being critical. > > Granted, an SO solution(people, processes, systems, etc.) isn't as > readily observable as a building. But are there not portions we can > point to as characteristic of SO? > > The obvious one is "that's a service over there." Cool. Then we > probably need to go a bit further and describe what makes it > a "proper" service, and not JBOWS (if JBOWS is not considered to be > SO). For higher level services I'd hope to be able to point at a couple of people and say "they do the Product management service" and to be able to point at a section of my repository that says "Product Management" and has the full lifecycle artefacts linked consistently together. Because SO is about full lifecycle thinking then companies that really do SO, rather than just do SOD IT, will be as obviously SO as York Minster. > > > > The service was order management. > > > > > > There was considerable focus on interfaces. > > > > Did you have a magic picture? > > We had one on the whiteboard for a while. :-) Which is why I did the method. Those pictures are almost always the most powerful ones in the entire project, but once we shift to implementation we get dragged into the weeds. The early simple pictures are the ones that _really_ matter. > > > > But why would that disqualify it from "SOA status?" > > > > It doesn't automatically but the odds are (IME) that messaging based > > solutions are using a more MOM approach where its about a series of > > discreet messages that are handled by applications rather than > > being a formal producer/consumer relationship. > > So many different agreements with and objections to this paragraph > running about in my head. > > A "MOM approach" isn't the problem. Services can and do use MOM as > the interaction vehicle. Yes. > > Discreet messages aren't the problem. Consumers/producers exchange > discreet messages. Yes. > > Formality of the relationship isn't an issue. The relationship > between message producer and message consumer can be quite formal, > yet said relationship may not pass "SO muster" in the eyes of some. > Said muster seemingly being hard to concretely define. Yes. > > Applications might be a problem. The exposed interfaces are generally > fine-grained and are often not "complete" from a service perspective. > App X and Component Y might both have a hand in providing Service A. Yes. > > But where an application encapsulates a service (or more), and the > interface(s) of the service are defined, then the application itself > is not an issue. Yes. > > With some slight rewording, your paragraph could be used to depict an > SO example: > > "Our implementation used a messaging based solution using a MOM > approach where a series of discreet messages are exchanged between > services (some of which are hosted by applications) in a > producer/consumer relationship." Which wouldn't be SO. If your "orientation" on a project is around the exchange of messages then its Message Orientation that you are doing. My point is that SO is about the thinking and style of the architecture to be SO from its start to its finish with the technology bits being about implementation. Approaches that take a technically oriented approach (e.g. by talking about messages) aren't (IMO) SO. Its certainly possible to say that "We had a series of discreet business services that all had formal definitions of their interfaces. The execution context (RM term) for the implementation used a Message Oriented Middleware." Now I might actually be agreeing with you here, all I'm saying is that the implementation is a slide 10 thing in the 20 slide deck in describing your SO solution. In a MOM deck it would be on slide 1. > > > > The RM list seems, um, spartan. > > > > I wrote a whole book on it ;) > > A decent one at that. Alas, it focuses purely at the business model > level. Yes, that level is important (most important?). I'm hoping for > a list of characteristics at the implementation level. 1) Looks like the business level :) > > > But seriously I'd say that services > > tend to be around functional nouns, so "Order Management" is a good > > example, it will have capabilities that are the verbs "newOrder", > > "createDispatch", etc and it will have priorities for its operation > > e.g. availability, response times, dispatch sizes etc. > > We agree emphatically here. > > > The point that I always come back to though is that how do you know > > that it isn't your ugly cousin and that its Catherine Deneuve? The > > answer isn't in the detail of a specific nostril, its in the overall > > big picture. Its that big picture that defines the architecture > > (the A) and how it does that defines whether or not it is service > > oriented or not. > > Many people find Angelina Jolie quite stunning. I find her relatively > scary. :) > > Sure, the big picture view is important. And the presence of a flaw > in isolation doesn't disqualify the entire picture. > > This point is well taken, and helps me reconsider the Oracle example > on the overall merits (though I still take issue with "meets the > business needs" as a characteristic that indicates SO being present). > > *BUT* > > We should be able to identify the list of characteristics. The RM > focuses on the service description, which is reasonable enough. What > is the list at the implementation level? Does one already exist > (partial or otherwise)? Can one be created? Or is it a fool's errand? I think it can be created, BUT there are lots of different ways to implement Services, all of which come back to RM compliance. What you could do is create characteristics for various implementation approaches. So you could have a SOA in MOM, SOA in REST, SOA in WS-*, SOA in flying monkeys, etc each with their own implementation characteristics. Steve > > -Rob > >
