Re: Re: Major Historical SOA Milestone Today
> If you look at what WSDL and the normal way people think about SOA is really > doing, it *is* just another approach to distributed objects. Disagree entirely. If by 'the way normal people think about SOA' you mean the RPC model, then this is definately *not* what most people that I know think about and indeed most modern toolkits implement as default for an SOA web service model. Even WS-I have deprecated the RPC-encoded model and RPC Literal is both un-necessary and typical not supported in most off the shelf web service stacks. Business services today are more often oriented to message exchanges that refer to complete or aspects of business processes (documents / composite services orchestrated via BPMs). Distributed objects also typically imply synchronous stateful interactions, whereas services are most often stateless (and often asynchronous - just like business processes), and where state management is needed, this is provided at the business process level via some form of specific state engine (e.g. a BPM). The danger of propogating the view that services are just an XML form of previous RPC based remoting architectures is that instead of designing service granularity around concepts that are meaningful to business (and most importantly to a consumer) you end up with a thin XML layer on the top of existing system API that leaks technical implementation details into the service interface and serves up the kind of tightly coupled, brittle implementation that business services underpinned by the tenets of SOA are intended to resolve. > .... It also means that you can > have a very open interface that isn't artificially restricted to the > specific problem-at-hand, but is more focused on a business operation > that can be used across contexts (for example, processing a specific XML > element within a larger message). > One other thing about the service interface coupling is that you have an > additional degree of freedom when it comes to versioning due to the late > binding and data coupling points mentioned above. If you don't have a > dispatcher in place already, you may need to put a proxy in place to > determine which service to actually invoke, but your external interface > can then adapt as needed to handle transition periods. Invocation > follows a standardized, uniform interface that doesn't need to change > with the implementation. This is quite interesting and comes up a lot not just for SOA but for any discussion on interface design. On the one hand you can design a very open/generic interface that rarely needs to change. This makes it very stable but comes at the cost of making it harder for consumers to know (and owners to specify) what data must be sent in order to request the required behaviour (this often requires some 'out of band' method for specification). This involves, as you say, a type of 'message discovery' process and then a secondary dispatching mechanism once the required service is identified from the content and its meta data. The other approach is to define a much more prescriptive interface for each specific business operation. This has the advantage that the technical interface definition in terms of its data model, expected behaviour, message exchange pattern, etc.. are unambiguous (although conveying semantics may still require some 'out of band' description), but the down side that the interface often is less stable in the face of desired change. Some proponents prefer the later becaues of its strong typing and often combine this with interface immutability (i.e. if something changes then its a new service/operation/interface/port-type/whatever). Others prefer it fast and loose ;-) Fraser. On 15/05/06, Andrew S. Townley <andrew.townley@b...> wrote: > Apologies if this discussion has gone a bit cold. Was away from email > last week. > > On Thu, 2006-05-11 at 20:47, Chiusano Joseph wrote: > > <Quote> > > But if you apply "object oriented" at the level of IT systems in the > > large, I believe that what you end up with is 100% equivalent to a > > service oriented architecture. > > > > Or could someone correct me? If I bumped into a service-oriented IT > > system in one bank on one side of the street, and an object-oriented IT > > system in another bank on the other side of the street, how would I tell > > which was which (other than by the choice of jargon on the Powerpoint > > slides)? > > </Quote> > > > > (2) Distributed object technologies (such as CORBA) do not enable > > "composition" of objects, as is possible with services. > > > > - With service orientation, one may combine multiple services to > > create > > a "composite service", in which multiple services are invoked at > > run-time by a single service (and these services may invoke other > > services, etc.). This limitation of distributed object technologies > > has > > led to their being largely superceded by the current SOA paradigm. > > I don't agree with this point because you *can* do composition of > distributed objects to create a composite service--even with a scripting > language so no compilation necessary in some cases. You may need to > deploy this as a separate service with a separate service interface, > but, in effect, that's exactly the same thing you're doing with > something like BEPL or WS-CDL. It has to run somewhere, it just may not > be quite as easy as drag-n-drop/point-n-click. That's a tool issue, not > a paradigm issue. > > > (4) Also, we can think in terms of the 3 primary aspects of object > > orientation and how they map/do not map to SOA: > > > > - Inheritance: Will be mappable for Web services (meaning WSDL-based Web > > service). WSDL 2.0 (still in process - W3C Candidate Recommendation as > > of 27 March 2006) has a feature for interface inheritance through the > > "extends" attribute information item. > > > > - Polymorphism: AFAIK, not mappable. That is, there is no standard > > mechanism for polymorphism for a Web service (i.e. "service context"). I > > foresee the need for a standard for this this in the future. > > > > - Encapsulation: Mappable. Both SOA and OO have the notion of data model > > (for SOA a service's data model, for OO an object's data model); also, > > with SOA, methods may be exposed as part of a service to access > > instances of the service's data model, while with OO, accessor methods > > may be exposed to interact with the data. Please note that this > > explanation was influenced by comments made by Duane Nickull on the > > SOA-RM TC list. > > While I agree with some of the points I deleted, I think the fact that > there isn't a 1:1 mapping between OO and SOA is *a good thing*. OO is a > good way to solve problems, but it isn't the only way. If you look at > what WSDL and the normal way people think about SOA is really doing, it > *is* just another approach to distributed objects. If this is taken to > its logical conclusion, I think a lot of the potential value of Web > services and by extension+association SOA the marketing term. The value > of SOA the architectural style will still remain, but we'll have to call > it something else just to get the projects approved. > > To answer Michael's earlier question, I think this is one of the reasons > people get confused. You can do SOA with distributed objects + > architectural discipline and you can do distributed objects with WS-*, > so they are sometimes very hard to tell apart. > > To me, the biggest differences between OO and SOA are (some of these > were mentioned by Joe already): > > * I think scale does matter for SOA, but, like before it depends on > context because you may see a business process where I see an individual > step in an overall business process. Where you have exposed a core > business function (by which I mean something related directly to what it > is you actually do to generate revenue--even at a departmental level > within an organization) and that business function can be invoked by a > 3rd-party (and I am still a fan of self-describing messages rather than > sequenced, distributed-object API calls) to perform an operation with > known side effects, I think this is SOA. > > Can you do this with OO? Yes, but generally you don't, generally it > must be synchronous, and generally it takes more than one interaction > between clients and the object(s) they're invoking. > > * Late binding is also a fundamental characteristic, but on a > system-wide scale rather than just an individual component or > subsystem. There are ways to do this in Java (dynamic proxies) and many > other languages, and some even have it built in (Objective C & > Smalltalk), but once you have a uniform interface defined along with the > known side effects, you can then have more than one implementation > available with different characteristics for different contexts. Maybe > this is due to physical proximity, cost of the operation, reliability > constraints, etc. > > Again, you can do this on a component level in OO, but it generally > isn't part of the design philosophy of your system, or, if it is, the > assumption of implementation variance is generally understood to be > within a given deployment and not a matter of normal operation. This is > why the business interfaces matter because if you can nail the way > people and organizations communicate across boundaries, it isn't so > important how things go on inside those boundaries. It also means that > if you can identify a new service provider (maybe something gets > outsourced; maybe you negotiate a cheaper service contract, etc.), > you've already identified the essential business communication paths, so > you can hopefully get them to implement the service interface you're > already using because it is specific to the process and not your > implementation. > > * Loose coupling at the data and service provider level. The service > provider level comes from the late binding discussion above, but it > ideally means that you should focus on the business capabilities that a > department or organization provide and then codify that interaction > rather than doing specific, task-specific implementations focused on how > a particular problem is done. In this way, I think SOA done correctly > helps clarify how your business communicates--internally and externally, > because if you don't understand that, you'll never build a decent SOA. > > >From the data point of view, Joe covered this in his email, but, at > least in our case, the idea is that you can process some or all of a > given message based on what it is you "understand" or based on other > context given to you with the message itself. This is why I think the > self-describing messages are so important. It also means that you can > have a very open interface that isn't artificially restricted to the > specific problem-at-hand, but is more focused on a business operation > that can be used across contexts (for example, processing a specific XML > element within a larger message). > > One other thing about the service interface coupling is that you have an > additional degree of freedom when it comes to versioning due to the late > binding and data coupling points mentioned above. If you don't have a > dispatcher in place already, you may need to put a proxy in place to > determine which service to actually invoke, but your external interface > can then adapt as needed to handle transition periods. Invocation > follows a standardized, uniform interface that doesn't need to change > with the implementation. > > I think that ultimately the scale issue is perhaps the biggest one > because you generally aren't thinking "in the large" with most OOA/D. > That doesn't mean you can't, and I would argue that if you are, then > you're really taking about coarse-grained service interfaces anyway, so > you really are using OO technologies to enable an SOA. > > However, the service within an SOA may not be something that's > automated. Maybe you have a real person on the end of that email > address (or team of people), or it may be a set of processes. The > important thing is that to the external world, whatever it is that the > email is requesting from a business point of view is what will happen > within the SOA. To me, that is the crux of SOA and what it means by > "business process" in all of these definitions under discussion. The > technology used to interact with the service is much less important than > a) that such a service exists and b) what the service does in a business > context for whomever or whatever requests it. > > ast > *************************************************************************************************** > The information in this email is confidential and may be legally privileged Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. > *************************************************************************************************** > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> > >
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format