[
Lists Home |
Date Index |
Thread Index
]
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.
***************************************************************************************************
|
