[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
Gents, Another issue that I see in the document is the fact that while SOA infrastructure
is global (services can be shared between the companies), while selection of
services and consequently service governance is typically local (within a given
enterprise). What I mean by this is the fact, that company A has a set of
services (S1, S2, ... Sn) is typically irrelevant to the company B. Typically
company B has an agreement with A (this goes to the hearts of trust) to use
service S1 and S5. When this agreement is reached, information about these to
services is created in company's A service repository, which is used for
deciding which services would be used for building solutions in this company. Service usage (with a few exceptions) is driven not by the fact the
service exists, but rather by the fact that there is an agreement between
companies to use them. This is often a difference between Mashups (often build
based on public service, like weather, routing, else) and SOA systems, based on
private, agreed upon services. This is relevant in two places of the SOA RA: ·
Service description visibility. ·
SOA governance. -----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. 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. 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. 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. 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 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. Long winded reply. But that's a little history of why we are
where we are today. 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]