[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] RE: A general comment on the SOA RA
|
Jeff, thanks for this lengthy reply. Once again, I am still trying to
get into your guys frame of thinking and basing a lot of this on my previous
experience and work. Let me try to answer some of your concerns below. At any
rate, if you guys do not want consider this, that’s fine. -----Original Message----- Boris, Starting with "architectural style" vs. "paradigm"
... In the Reference Model (RM), we purposely targeted a much broader
audiences than just techies, e.g., architects. It was intended to be readable
to non-IT people as well as IT people. We purposely contrasted SOA with
OO at the paradigm level. As you know, OO concepts were introduced in the
1960s but the paradigm didn't begin to take hold in industry until the early-
to mid-1990s; almost 30 years hence. While pundits are considering SOA to
be dead, it too is a paradigm shift that will likely take years before its
value will be more broadly seen in industry. I agree – SOA is a
paradigm shift. What exactly does this mean? In my mind it is a paradigm shift
because SOA is all about business aligned services and business processes,
orchestrating those services into solution. But you may ask, how it is
difference from OO? My answer would be two fold: ·
OO is decomposition of the application,
where as SOA is decomposition of IT assets in general ·
Objects can be anything, for example
linked lists, while services have to be aligned with business functionality (more
on this later) In the RA, we expand on the paradigm notion introduced in the RM to a
SOA ecosystem perspective. I certainly understand the point about
connecting this to the complexity of the Web, but we're really focused on the
"service Web" vice the early "document (hypermedia) Web,"
"Semantic Web," or more recent "social Web." My
words, sorry. I am sorry, I was trying
to be sarcastic here. When people compare SOA to Web it makes me very nervous. Web
is collection of resources – any resources, while SOA is about specific
resources – business aligned services. To be precise, the RA is an architectural description of the paradigm
that is SOA. It is not a solution- or enterprise-oriented RA. And
that is why we're in discussions with The Open Group on harmonization efforts
because their efforts are focused on the latter, which again, is techie
focused, e.g., architects. Not that that is a bad thing, just more limited in
scope. This is why I think characterizing our RA as foundation work is
important. Sorry, this reminds me
the arguments that I have often heard from ESB vendors (nothing personal) –
“buy or product and you will have SOA”. The issue here is that with
the most wonderful paradigm, crappy services lead to a crappy SOA. All of us
have seen systems, which were using object decomposition for defining services
and then claimed that SOA does not scale. A few comments now about the term "architectural
style." Even architects don't agree on a common definition of
architectural style. The folks out at the CMU Software Engineering
Institute (SEI) define it as follows (see
http://www.sei.cmu.edu/architecture/glossary.html): "A specialization of element and relation types, together with a
set of common constraints on how they can be used. See architectural
pattern." What the heck does that mean? And obviously this definition means
that you need their definition of architectural pattern. Let's see,
here's how they define that term: "A description of element and relation types together with a set
of constraints on how they are used. The term architectural style has
also been widely used to describe it." (Looks like a circular definition to me.) Guess that means we need to know what "element" and
"relation" means in their context. Well those definitions are
provided in the above link as well. But then Garlan and Shaw (both of whom are CMU/SEI folks) define
architectural style in their book as: "A form or pattern of design with a shared vocabulary of design
idioms and rules for using them." Well that seems to make a little more sense than the earlier
definitions, but once again that word "pattern" keeps creeping
in. So we have two different definitions of architectural style FROM THE
SAME organization, which is usually regarded as one of the leading
organizations in the world on software engineering and software architecture. The problem here is that none of this makes sense to the layman, or to
the non-techie CEO or business person. And in the RM, we very much wanted
a very broad audience. For the RA, we build on the RM core so we of
course adopt the notion of paradigm. No it does not. But what
does this mean? In my mind this is abd definition – end of story. On
another hand, SOA RA starts by explaining that SOA is architecture and refers
to the definition of what architecture is. You do not consider this too
technical right? Now about this definition from Richard
Hubert’s Convergent Architecture: Building Model Driven J2EE Systems with
UML. Wiley, 2001 ISBN: 0471105600 - “An architectural style is
a family of architectures related by common principles and attributes”. I
think this is quite readable. Now, on the subject of "business services" ... What do we mean by "business?" Heck, we fly spacecraft
where I work and we very much use SOA in our modern ground systems. So
does business just mean the 'aerospace business' and flying spacecraft in our
world? I guess it could. Or does it mean the more traditional
profit or organizational oriented context of business such as a company? I think the alignment element here is what the perceived value is in
SOA and that is agility. In our "business" of flying
spacecraft, I have always taught our folks that what we strive for is a
"composable" ground data system (GDS) rather than building huge
monolithic And this is fine. Every
business is different. Business service means (for me), that people (often non
technical) can understand what the service does, based on its name. On of the
definitions, that I have seen sounds roughly like this: “If you can’t
explain to your CEO, what this service does, do not bother implementing it. GDS applications that are unique to a specific flight project and very
difficult to modify for the next flight project. By breaking down GDS
functionality into composable chunks (i.e., services), then we can make our
"business" more agile by rapidly composing functionality specific to
the needs of a flight project customer in a much more rapid and efficient
manner. Finally, there's this notion of alignment with business processes that
leverage services. That's a good thing and something we talk about in the
RA in terms of service-oriented business process (and service-oriented business
collaborations). But, as you know, we don't want to infuse process
modeling directly into the service level but rather keep it at a higher level
of abstraction just as services abstract functionality of components in a
component level, which may in tern be abstractions of objects at an object
level. Just as Duane has always reminded us that to infuse process
modeling directly into the services would be considered an 'anti-pattern' in
this case. With all do respect to Duane
I am not sure, that you can do this (but he is the boss). The issue is that if
your do not specifically design your services to be composable, then using them
in a business process can be very problematic. On another hand, if we agree
that services are business services, then a common way to define them is
through decomposing a business process. So no matter how you approach this, a
business process still has a big role and separation of SOA from BPM is
artificial and typically leads to more issues down the road. Long winded reply. But that's a little history of why we are
where we are today. And a final issue, that
you haven’t addressed. SOA is rarely a “green-field”
implementation. As a result transitioning from traditional architecture to SOA
is a complex undertaking, which is an integral part of SOA. Message to Frank. Frank, did you send out a PDF of the latest
snapshot? I didn't see it. Maybe you just send it to the assigned
readers from the last call. Cheers... - Jeff -----Original Message----- From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com] Sent: Friday, April 03, 2009 3:53 PM To: soa-rm-ra@lists.oasis-open.org Subject: [soa-rm-ra] A general comment on the SOA RA I have finally finished reading and realized where I had the biggest issue with this. The document equates SOA (for the main part) with a complex distributed system, leaving completely aside Business/IT alignment nature of SOA. Unless we stipulate from the very beginning, that services are representation of well-defined business artifacts, there is no difference between SOA and, for example, The Web. I would think that
Web is even more complex. So, in my mind, "SOA can be defined as an architectural style promoting the
concept of business-aligned enterprise service as the fundamental unit of designing, building, and composing enterprise business solutions. Multiple patterns, defining design, implementations, and deployment of the SOA solutions, complete this style." http://www.ibm.com/developerworks/architecture/library/ar-soastyle/ Similar definitions can be also find at: http://www.opengroup.org/projects/soa/doc.tpl?gdid=10632 and
indirectly at http://www.jot.fm/issues/issue_2008_11/column6/index.html Please, let me know if this makes sense? If it does, then the document lacks a few other things that can be easily added. But lets first agree on this slight change of a
viewpoint. Boris The information contained in this communication may be CONFIDENTIAL and
is intended only for the use of the recipient(s) named above. If you are
not the intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this communication, or any of its contents, is
strictly prohibited. If you have received this communication in error,
please notify the sender and delete/destroy the original message and any copy
of it from your computer or paper files. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS
at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS
at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]