On Wed, Jan 7, 2009 at 22:01, Michael Poulin <[email protected]> wrote: > Integration of the services, sorry, collaboration, is not or should not be > the same thing as application integration we know today.
Sure. I'm an old-time semantic data modeler who wish the world would hurry up and understand the amazing zoot! bang! crash! powers of ontologies in integration projects. > Yes, we need a > flexibility to combine components, better be services, in new compositions > as easy as possible. My only concern is that it should not be done for the > cost of changing the service itself. Um, what should the cost be? :) It's quite often when integration-time appears you discover that your design suck, and the best thing to do is to go back and do it over again. Yeah, sure, we really don't can't afford too much of this, but I have a very strong policy in everything I do (for myself, for clients, for the company) to plan with failures in mind; this is about small, flexible services that won't be too expensive to do all over again. I think we agree, though? > If 'ad hoc' is equal to 'as needed', I am fine but if it is > about reckless integration, for the sake of connecting the things w/o > considering the context and consequences, I am not fine at all. I think no one proposes to be stupid here. :) > If we deal with atomic services, they do not need others to fulfill their > obligations, i.e. to provide promised business functionality and RWE. We > cannot rid of them because they represent the lowest level > of business functionality, i.e. they implement an atomic business function > or feature. So, we need a mechanism that can extract service capabilities > and use them in different collaborations (but w/o modifying collaboration > participants). We have orchestration for this. Is this enough? Well, if you mean BPEL (without getting into the whole Orchestration vs. Choreography thing again) and you want to hang out with the WS-* stack all year, I'm sure it is "enough", where "enough" refers to how well you master your WS-* stack with tools, sticky-tape and patience. I personally am not too happy applying BPEL to these things, because, frankly, I find it ugly and confusing as anything (which, admittedly, could be all my fault), and like to shift some (most?) mechanisms of orchestration and / or choreography to some REST level protocol instead (with the disclaimer that I probably don't design systems overly complex, and don't need all the whistles and bells). > What we need to add, if any, "to make it as easy as possible to assemble > (dare I say integrate) components into a working whole on an ad-hoc basis"? This is an interesting thing for me, because I'm about to venture into an adventure (new job, new country, new everything) of using Topic Maps and ontologies to model these very things (integration on application and service level, orchestration and choreography, extensions, monitoring, hosting, SaaS, etc.) , making the model "API aware" so to speak, having a model with a domain-model map up all the pieces which are typified (and further extended semantically to denote their capabilities, APIs and so forth) in a more ... shall we say, "human" way of modeling these things, making it dead easy to shift them around without breaking anything. I'm sure I'll talk more about this as I get going on it. Kind regards, Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
