In the vein of "I don't always agree with everything I say...." :-)
Can one successfully argue that integration is essentially about defining interfaces? Component A needs to interact with Component B. We might define a point-to-point interface between them, with A creating a flat-file that only B understands. Export. Transfer. Import and process. We might have B define a general purpose interface, which covers all or most of the anticipated interaction needs. Any other component is free to use the interface, just need to adhere to the syntactic and semantic constraints--published or not. We might have B support multiple interfaces, with multiple formats and multiple protocols. I think this is the spaghetti that most companies have, no? :-) Interfaces are the core aspect of integration. Does that sound reasonable? SOA is predominantly an exercise in defining interfaces. From Gartner: "A service interface is the design essence of SOA." And this: "The interface is the fundamental, definitive component of a service." Without the interface, the capability is all but useless as it cannot be used by anything. If interfaces are the core aspect of integration, and SOA is characterized by a focus on defining interfaces, does it stand to reason that SOA is fundamentally an approach to integration? Is it reasonable to conclude that SOA is primarily about two things: capabilities and integration? Consider that service consumption still fundamentally behaves in the same ol' "export, transfer, import" approach but with "modern" techniques for doing so. Intead of writing a fixed-length file to disk, the consumer creates an XML representation in memory. This creation is specific to this interface, since it is unlikely that the consumer works with the data natively in XML form. Instead of using FTP to move the file, POX over HTTP or SOAP over HTTP or POX over messaging or some other "modern" transport mechanism is used. Instead of reading a file from disk for import, the service accepts the document via the transport above and begins processing. First validating the request (authorized, format is right, etc.), interpreting it (since, like the client, the service doesn't natively work with the XML representation, it will transform the XML into some internal representation) and then performing the work. SOA is about integration. But as I've said before, that isn't all it is about. It's about capabilities and about integration as a part of exposing those capabilities to the world. -Rob --- In [email protected], "Rob Eamon" <rea...@...> wrote: > > SOA is a form of integration. But integration is not the primary > focus.
