[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Major Historical SOA Milestone Today


difference between soa and ooa
Hi Fraser,

On Mon, 2006-05-15 at 23:42, Fraser Goffin wrote:
> > 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).

I think part of the reason you (understandably) misunderstood what I
meant about RPC was that I didn't state my point very clearly.  :)

I wasn't talking about the RPC vs. doc-lit feature of the toolkits, I
was talking about getting past the RPC/distributed objects wiring in the
brains of developers and architects.  It is quite possible to have what
I call RPC-style services implemented in terms of document message
exchanges.  We have a few of these, and sometimes they're useful. 
However, what I've personally observed is that getting people designing
and implementing services to think in an asynchronous manner is actually
quite difficult when the rubber meets the road.  Conceptually, it seems
to be clear to them, but then when the service interactions are
designed, they're still based on an assumption of synchronous
request/reply interactions.

While it may be more coarse-grained than what you're referring to, it's
still fundamentally an RPC style of interacting with services.  Like I
said, sometimes it is necessary and even desirable, but if you do it
when you don't need it, it causes you serious scalability issues.  Any
lookup type of service would fall under my definition of the "RPC
style".  I elaborated on what I think the different styles of service
interactions are in http://sdec.reach.ie/rigs/rig0019/ (the
auto-generated HTML is a bit ugly, so I'd recommend the OpenDocument
version if you go looking).

Based on what you've said, maybe you're seeing a different dynamic.  If
this is true, then I think it's fantastic.  I can only comment on what I
experience, see and read, and I've been pretty busy lately, so I may
have missed a lot.

> 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.

I completely agree with you on this point, and that was one of the
reasons I was trying to make the original points above (apparently
badly).  However, I still have issues with the tool support vs.
developer and architect understanding of what this really means in
practice.  The numbers of people who understand the issues you describe
is growing, but I don't believe that this level of understanding has
critical mass within the industry.

> > .... 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 ;-)

I'm certainly in the latter camp.  I learned the advantages of late
binding with NEXTSTEP and Objective-C (I know this isn't the earliest
example, but it's the first time I used it).  It isn't always the most
efficient approach to every problem, so that's where we get to earn our
paychecks, but I prefer it as a starting point to the opposite approach.

Also, in the context of SOA and service interfaces and the
practicalities of dealing with
network/firewall/infrastructure/deployment changes either across
organizations or within larger organizations, I want a clearly
established and functional communications channel that I can leave alone
and deal with the complexity on each end of the pipe.  If you've good
plumbing in place with primarily asynchronous services, you still have
the ability to insulate the service implementations from those things;
you just do it in a different place.  In my opinion and experience, it
also improves your overall interoperability because there's less moving
parts to agree on between parties.  I've lived through the evolution of
too many distributed systems--even with coarse-grained APIs--to not want
to avoid that pain if at all possible.

As for the message discovery process, it doesn't have to be entirely out
of band or manual, but something like WSDL won't handle the extra layer
of indirection for you.  This is something I tried to do for a while
before I finally gave up.  I haven't actually attempted this with SSDL,
but, if I understand the concepts behind its development, I think it
must be able to do this sort of thing.  Solving this issue for us is
something that's on my "to do" list, but I don't think it'll happen for
a while.

Hope this is a little clearer than the last one, and if I'm
misunderstanding the current state of "general understanding" of how to
do SOA, I'm more than happy to be wrong. :)

ast

> 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>
> >
> >
***************************************************************************************************
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.
***************************************************************************************************


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.