RE: A general comment on the SOA RA

["Estefan, Jeff A" <jeffrey.a.estefan@jpl.nasa.gov>]

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