On Sat, Jun 14, 2008 at 2:35 PM, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > Anne Thomas Manes wrote: >> The technologies used to implement a service or to manage interactions >> between service endpoints will certainly impact the performance and >> resiliency characteristics of the services environment. But IMO the >> point of this discussion thread is that a particular technology choice >> does not help define what is or is not service-oriented. > > And I don't think service-oriented-architecture tells me whether I can make > use > of a piece of software in my infrastructure. It just tells me that it's a > piece > of software that has services. It doesn't say whether it needs a transaction > service. It doesn't say whether it has a fail-over capability built in or if > I > have to deploy multiple instances. It doesn't tell me if these multiple > instances will "synchronize" themselves or if I have to have a hard > fail-over > and the backward recovery mechanism. SOA doesn't say whether there is a web > based UI, a pencil and paper part, a windows GUI, a blue-ray disk recorder > or > anything else. It's horribly non descriptive.
I haven't discussed what I call "service models" yet in this thread, i.e., best practices for design and description of services. As I indicated in my last response to Rob, SOA does not *require* a comprehensive infrastructure which can manage and automate infrastructure capabilities, nor does it *require* adoption of service model best practices. But for the most part, the environment will not be very successful without them. Most folks describing SOA claim that service descriptions are a cornerstone requirement of SOA -- but they don't provide much meat regarding the types of descriptions that are required. (i.e., WSDL is not enough) Service descriptions should include policies that describe the constraints and capabilities of the services, and they should give you sufficient information to determine whether a service meets your needs and how you must interact with it. > >> And if you >> want to build services in VB6 because that's where you have strong >> development skills -- have at it. Few people would do so today, but >> that's because VB6 has a lot of intrinsic flaws -- not because it >> wouldn't work. > > The flaws would create issues that would effectively make it "not work". I disagree. You can build services with languages such as JavaScript and PHP, too. Bear in mind that in the model I've described, the service is not responsible for the communications infrastructure. VB6 is perfectly adequate for building a relatively simple service. > >> I'm hesitant to call SOA client/server because it implies synchronous, >> request/response interactions. SOA does not constrain the types of >> interactions that services can support. > > As I said: > >>> Client/server, while an interestingly descriptive term for Service >>> Oriented >>> Architectures doesn't really detail anything that isn't already known. > > There are clients and servers, this we know implicitly... > >> SOA doesn't impose very many constraints at all -- but mostly because >> it's not describing implementation details. SOA is an architectural >> style in which capabilities are modeled and implemented as "services". >> A service encapsulates its capabilities and makes them available to >> applications and other services through one or more types of >> interfaces. > > If I told you that I had a new SOA service that I had been working on, and > knowing what you know about my preferences of platforms, would you assume > that > you could deploy it with an arbitrary "interface" immediately? Did "SOA > service" tell you anything specific about the choices you'd have with my > swift > new service? "Immediately" -- no. Because I assume that the container you used does not support clean separation between interface and implementation. That is a constraint you impose on your service through your choice of platform and technology. But I'm quite certain that you could build an abstraction layer into your infrastructure that could expose your service capabilities through interface types other than tuple spaces and protocols other than JERI. > >> For broadest usability, the service should expose its >> capabilities through whatever styles of interfaces and protocols its >> consumers desire: >> - method-oriented >> - resource-oriented >> - topic/queue-oriented >> - tuple space-oriented >> - whatever-oriented > > Yes, but now you are talking about technologies because this is where the > rubber > hits the road. SOA doesn't tell you that all these things are possible! It > just tells you that there are services and clients in the architecture. It's > only all these discussions in forums and written down "descriptions" and > "definitions" on various "vendor" and "consulting" web sites that have added > all > the details that you spent several hundred words to convey in your response. > If > you have to use all these words, then SOA is not an informative indicator > from > my perspective. I agree with you. As I said, SOA does not impose very many constraints, and it definitely does not specify that any specific technologies must be used. The basic constraints are: - capabilities must be modeled and implemented as services - a service should maintain clean separation between its interface(s) and its implementation - a service should provide a description of itself that enables consumers to determine if and how to use it. SOA does not require a service to expose its capabilities through multiple interface styles. I'm suggesting it as a best practice. Notice I said, "for broadest usability". > >> For easier development, a service container/platform should maintain a >> clean separation between the service implementation and the various >> types of interfaces exposed to consumers. I.e., a developer should be >> able to implement the service capability using whatever language and >> component/service model he prefers. The various interface styles could >> then be modeled and mapped to the service capabilities as needed. > > This is a technology enabled capability. Does VB6 have a JERI stack out of > the > box? Does JERI support DCOM out of the box? You have to know somethings > about > the language platform the system was developed under and you have to know > some > things about the capabilities of the system implementation. Ah.. but here's the secret: VB6 doesn't need to have a built-in JERI stack for a service implemented in VB6 to communicate via JERI. The service container should provide the necessary abstractions and translations to enable the service to communicate using whatever protocols its consumers want to use. > > ...This is why I keep saying, we really should just stop kidding ourselves > and > standardize on one "technology" that goes from the programming layer through > the > deployment layer. Only then would the "technology" not matter. But this assertion isn't realistic. The industry will never standardize on one technology. > >> For greater resiliency, a services infrastructure should manage >> interactions with service endpoints. The services infrastructure >> should manage discovery, binding, session management, failover, >> retries, recovery, rollback, compensation, authentication, >> authorization, auditing, message confidentiality and integrity, >> routing, transformations, etc. A service developer should not be >> burdened with implementing these infrastructure capabilities. They >> should be managed and configured separately from the service >> implementation. Likewise, a service consumer should not be burdened >> with implementing these infrastructure capabilities. It should be able >> to consume a service using its preferred interaction style, and it >> should be able to rely on the infrastructure to ensure that >> interactions are properly managed. > > Service infrastructures are technology specific. They use operating systems, > and programming languages to provide specific features. There is not one > "infrastructure" which exists today, that support every transport type of > the > past, and has everything that we need in the future. Technologies come and > go, > because of improvement and because people vote with their feet. They really > do > matter. Virtualization is a beautiful thing. Most modern Java containers have adopted the POJO component model. As a developer, you for the most part don't care what container you use, what operating system its deployed on, or what communications stack implementation you use. (You are still aware of whether you are using RMI, JAX-WS, JAX-RPC, JMS, JERI, etc -- but you don't care which implementation of each stack you use.) Infrastructure continues to get more abstract and virtualized. Today you can't go out and buy a ready-made infrastructure that supports the model I've described, but we're getting closer every year. At least now we have the ability to build part of the infrastructure using an assortment of related products. > >> Technology can obviously impact the resiliency of this infrastructure. >> But many different types of technology could be used to implement >> services and the infrastructure. And use of any specific technology >> does not indicate this type of design. Hence the assertion, "SOA is >> not about technology". > > SOA is a term that attempts to say something about the architecture of a > system. > It's great for high level people to spit out at each other over their > favorite > dinner and beverage. But, it doesn't tell them anything about the cost of > the > system, the integrity of the system, the life cycle of the technology used > or > anything else, that in the end, controls what actually happens when you turn > it on. The combination of SOA design principles and the infrastructure implementation should give you a pretty good sense of the costs, integrity, and lifecycle of the environment. It doesn't make a lot of sense to implement the infrastructure, though, if you don't intend to adopt the design principles. Conversely, I think adoption of the design principles yield tremendous value in TCO even without the infrastructure. > > "SOA is not about technology" is an okay statement to make, in the right > context. > > I think that it might be more informative to use a phrase such as "The term > SOA > is really only useful in discussions where one either doesn't know or care > about > the technologies of a system". I disagree with you. SOA design principles apply every time you implement a service. You need to select technologies to implement a service. My contention is that you should select the appropriate technologies that best address the requirements of the service and its potential consumers. > > Gregg Wonderly >
