[
Lists Home |
Date Index |
Thread Index
]
No worries! :)
On Tue, 2006-05-16 at 12:37, Fraser Goffin wrote:
> Andrew,
>
> actually re-reading your original email (more carefully) I can see
> that we agree on most (probably all) of the things I was grumbling
> about (I'm always a bit grouchy on a Sunday night :-). I *do* agree
> that utility services (and actually even some business services can be
> modelled) in an RPC 'style', we use this for one of the ones you
> mentioned (looking up reference data - aka. code lists).
>
> The point you make about synch vs. async is extremely topical to me
> right now. I have for a while been trying to explain to our design /
> architecture team that whereas a synchronous model on paper looks
> attractive, and there are indeed aspects of an overall busines process
> that *must* be conducted that way, if we really want to be able to
> scale as well as implement expected reliability assurances into our
> services, then we need to squeeze those pieces out and implement them
> asynchronously. Of course this can have an impact of the way that
> business processes currently operate and it can take a while to
> convince our business colleagues that they aren't losing anything (and
> hopefully gaining a great deal).
>
> I work in the implementation team (much more fun than ivory tower
> stuff) and as you say, when the 'rubber hits the road' physical
> practicalities come into play.
>
> Actually looking back over what I've just written, your probably right
> about the level of understanding of this stuff, so probably I need to
> practice a bit more patience :-|
>
> Regards
>
> Fraser.
>
> On 16/05/06, Andrew S. Townley <andrew.townley@bearingpoint.com> wrote:
> > 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@bearingpoint.com> 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.
> > ***************************************************************************************************
> >
> >
***************************************************************************************************
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.
***************************************************************************************************
|
