Javier Casta��n wrote:
> Ashraf Galal wrote:
>
>
>> SOA is so valuable to businesses because it enables _process optimization. _
>>
>> In order to optimize processes, we need to know which processes are
>> relevant and we have to understand them - something that _*cannot be
>> done */*without business process modeling. */_
>>
>>
>
> I have lots of legacy apps working in batch mode. Whenever one
> application is going to be demised one, thing I plan to do is to look at
> file transfers coming in and out of the soon to be demised application
> and then decide which part of the problem is solvable via common data
> storage and what part needs to be implemented like services.
>
> A big bang approach where all business processes were analyzed would
> take ages to complete.
>

SOA takes a path different from the traditional approach which was based
on the "big bang" approach, where processes were first modeled, then
optimized, then implemented.
>
>> There is a major problem with this approach - a semantic gap between the
>> process model and the applications.
>>
>> We need to bridge this gap.
>> We need a  a pragmatic approach to business process modeling using the
>> Business Process Modeling Notation (BPMN) and the automatic mapping of
>> BPMN to the Business Process Execution Language (BPEL), which is the
>> de-facto standard for executing business processes in SOA.
>>
>>
>
> Perhaps because in the scenario I described I'd be using services as an
> strategy for application integration, but otherwise I don't see it as a
> good fit for BPMN.
>
> So I don't share the notion that BPMN is absolutely necessary in order
> to perform SOA.
>

*SOA introduces technologies and languages that reduce the semantic gap
between the business processes and the actual applications (code). *

Particularly important here are *BPMN*, which is used for modeling
business processes, and *BPEL*, which is used for the execution of
business processes.

With these two technologies, plus some additional ones, SOA provides:

- A language�BPEL�for direct execution of business processes

- Round-trip mapping between the process models in BPMN, and their
executable representation in BPEL

With this, SOA considerably reduces the semantic gap between the
business processes and application systems.

*BPMN enables us to draw the representation of a business process, which
is then mapped into the executable BPEL code, and executed directly on
the SOA platform.*

All the best

Ashraf Galal

> Regards
>
> Javier Casta��n
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

2009/12/8 Ashraf Galal <ashrafwg@...>:
> "Not quite true. If the client side is doing XML schema validation then
> the new attribute will blow their validation based on the old
>
> schema. �This isn't any different from using RPC style and although I'd use
doc/literal for exchange in WS-* I'd still consider it an RPC
> style of communication."
>
> A major problem in adopting RPC style is that, the exchanged XML
> documents cannot be validated against an *XML Schema Definition (XSD).*

Errrr why not?  Now I ask because back when the whole doc/literal v
rpc stuff was going on I had a project that ended up using the RPC
style of encoding and it pretty much appeared to us that it was doing
full schema validation.

The validation can be done in any exchange mechanism.

>
> Let's discuss SOA and BMP:
>
> SOA provides the technology platform for the implementation of business
processes, and the development of applications that provide end-to-end
> support for business processes.
>
> Business process modeling for SOA outlines the importance of BPM and its
life-cycle, which consists of business process design, process
> implementation, process execution and control, and process optimization.
>
> Modeling business processes for SOA and developing end-to-end IT support for
these processes have become top IT priorities for many organization.
>
> The SOA approach is based on services and on processes.
>
> Processes are focused on composition (orchestrating) of services (fine- or
coarse-grained) and discuss in that sense services (fine- or coarse-grained)
become process activities.
>
> Experience has shown that the implementation and the optimization of
> processes are the most important factors in the success of SOA projects.

This would be your experience.  Mine is that the most important
success factor in SOA projects is having clear units of management
(lets call them Business Services) which domain processes and other
elements and provide clear management boundaries.



>
> SOA is so valuable to businesses because it enables _process optimization. _

Errr Six Sigma enables process optimisation, LEAN enables process
optimisation. Value Network thinking means that process optimisation
isn't such a key thing in complex organisations its actually about
network optimisation and balancing.


>
> In order to optimize processes, we need to know which processes are
> relevant and we have to understand them - something that _*cannot be
> done */*without business process modeling. */_

Want a bet?


>
> There is a major problem with this approach - a semantic gap between the
> process model and the applications.
>
> We need to bridge this gap.
> We need a �a pragmatic approach to business process modeling using the
> Business Process Modeling Notation (BPMN) and the automatic mapping of
> BPMN to the Business Process Execution Language (BPEL), which is the
> de-facto standard for executing business processes in SOA.
>
> We need also to cover related technologies such as Business Rules
> Management and Business Activity Monitoring, which play a pivotal role
> in achieving closed-loop Business Process Management.
>
> It is true and it is fact and practical if we can change our mind and
> think in different way than we got use to think.
> Thanks to_ __Matjaz B. Juric
>
<http://acm.books24x7.com/search.asp?qdom=author&scol=%7Ball%7D&qstr=Matjaz%20B.\
%20Juric>_ and Kapil
> Pant
>
<http://acm.books24x7.com/search.asp?qdom=author&scol=%7Ball%7D&qstr=Kapil%20Pan\
t>
>


BPEL on Web Services is just a technology solution, its not "SOA"
because you have used a few buzzwords.  My current programme has

1) A clear business Service architecture
2) A clear set of capabilities for those services

And from here we are heading into formal contracts for the services,
including the engagement processes that people need to follow etc etc.
  But all of this is controlled and domained by the business services
which provide us with the governance structure which can drive our
project forwards.

Technically we have pretty much everything you can shake a stick at,
BPEL, rules engine, package solution, Web Services, standardised
schemas, integration, ETL, etc, etc

None of those technical things make the programme "SOA" and having
BPEL doesn't provide us with the only mechanism for optimising
business processes.

The point here is the difference between the EXECUTED business
processes and the PERCEIVED business process.  It is the later which
needs optimising and in many cases there is no direct executed process
or the executed process has only a tangential relationship to the
perceived process.

As a great example of why process isn't everything.  Sales.  People
claim there is a "Sales Process" but what they really mean is that
there is a "Sales pipeline reporting process", optimising Sales
people's work isn't about process optimisation its about information
presentation.  You SEE the improvement through the measurement process
(the perceived process) but the optimisations are in no way applied or
managed through that process.

Steve
>
> �All the best
>
> Ashraf Galal
>
> Steve Jones wrote:
>> 2009/12/8 Ashraf Galal <ashrafwg@...>
>>
>>>
>>> If any changes need to be done in the RPC style, it must affect the
>>> server and the clients. There is no doubt about that.
>>> For the document style communication, The fact that objects are
>>> serialized and deserialized to and from an XML stream, most structural
>>> changes can be introduced with zero-impact.
>>>
>>> For example, in a document/liter wrapped style, we might have a an
>>> outcome class that has two attributes: returnMessage and returnCode.
>>> There are some consumers who bind to it.
>>> We will add a new attribute "other", to it.
>>> The server module can now assign a value to the new attribute and the
>>> clients that update to the new outcome class can receive that value.
>>> But what about the clients who do not update? Well, they will continue
>>> to work in the same way.
>>> They will obviously not be receiving the new value, but the
>>> deserialization process will not break.
>>>
>>
>> Not quite true. �If the client side is doing XML schema validation
>> then the new attribute will blow their validation based on the old
>> schema. �This isn't any different from using RPC style and although
>> I'd use doc/literal for exchange in WS-* I'd still consider it an RPC
>> style of communication.
>>
>>
>>> On the other side, we can remove an attribute (for example,
>>> returnMessage) in the server module, and have a non-updated client
>>> receive a null value in this field, though still working.
>>>
>>
>> Only if it can accept null, if this was a mandatory field then again
>> the client will explode.
>>
>>
>>> When we decide to model business processes, that means we takes the
>>> business logic out of the application and invoke the applications from
>>> the business processes tool. This means refactoring the existing
>>> applications, if needed.
>>> It is now facts and practical and not theory at all, but we have to
>>> understand the pig picture and change the ways that we have got to do
>>> the job.
>>> It is not an easy task.
>>>
>>
>> BPM tools are applications, just because its in XML doesn't mean it
>> isn't code. �I personally am fed up on how people think that BPM tools
>> are some sort of magic. �Its plain old Visual COBOL, a nice GUI on a
>> process oriented world. �This means it has the same challenges as
>> traditional procedural coding systems and I've seem more car crash BPM
>> solutions than I care to mention. �Sometimes they are the right
>> approach, sometimes they are not the right approach but what ever they
>> are they are a TECHNOLOGY platform in which you build TECHNOLOGY
>> solutions.
>>
>> Its not magic, its not a silver bullet. �It can help when used well
>> and can destroy projects when used badly.
>>
>> Steve
>>
>>
>>> All the best
>>> Ashraf Galal
>>>
>>> Michael Poulin wrote:
>>>
>>>> I am afraid that beside relatively known and trivial facts, the tone
>>>> of the statements is a bit orthodoxy...
>>>>
>>>> For example, "We cannot achieve it [upgradeability] if we use RPC
>>>> style communication but we can achieve it very easily if we use the
>>>> document style" - it is really impossible to upgrade RPC? I doubt on it.
>>>>
>>>> This statement is almost revolutionary: "This is why it is better to
>>>> design service at a fine-grained and composite them together." As I
>>>> recall, the design of services always recommended to consider
>>>> coarse-granular approach. Composition of service of absolutely
>>>> different granularity targets not just a 'Facade' pattern ( covering
>>>> fine-grande interfaces with a coarse-grande one) but creation of
>>>> business functionality with new capabilities, IMO.
>>>>
>>>> "If we do so, we can easily achieve the immutable service and any
>>>> changes will only be done on the composite services, version..etc." -
>>>> I do not think we may say so because it depends on particular change
>>>> in the business environment - some new industry regulations can
>>>> affect the very fundamental things implemented in the lowest level of
>>>> business services. There is no such thing as 'immutable' for the
>>>> entities viewed and operating in the changeable external environment.
>>>>
>>>> "We will not have any management problems with composite services
>>>> because we can discard any of them and rebuild them from scratch
>>>> without even
>>>> affect the underlying services." - to me this sounds a bit idealistic,
>>>> especially when we address management. We have to remember that the
>>>> clearance and concrete relationship between the elements of the
>>>> technical system do not consider many other aspects that exist in
>>>> management, for example. In particular, if you are the owner of the
>>>> service composition and want to re-compose it, you are in full power
>>>> to 'de-construct' the existing composition but you have to obtain new
>>>> permissions to use the old elements /services in the new one (if
>>>> you are really in the SO environment). So, for management, this
>>>> re-negotiation of use of existing services in new combination may be a
>>>> challenge. This is the problem of ownership and management boundaries,
>>>> not technical problem.
>>>>
>>>> I think that the problem with IT with regard to SOA or other
>>>> architectural/technological things is in that IT Management assumed it
>>>> might decide what to do while this 'role' should belong to Business
>>>> and Architecture exclusively. No SaaS/Cloud will help until they
>>>> would follow architectural solutions dedicated to resolving concrete
>>>> business problems. The major trick here is that technology vendors
>>>> cannot properly guess what these problems are in many cases, and they
>>>> know about this. Thus, they have to change their appeared from 'we
>>>> have the hottest and cool technology available to you(IT)' to
>>>> something that fist shows the business value of the product and the
>>>> 'cool' part only the second. And this is not that easy and quickly to do.
>>>>
>>>> - Michael
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------
>>>> *From:* Ashraf Galal <ashrafwg@...>
>>>> *To:* service-orientated-architecture@yahoogroups.com
>>>> *Sent:* Fri, December 4, 2009 5:32:01 AM
>>>> *Subject:* Re: [service-orientated-architecture] Miko on SOA Governance
>>>>
>>>> Another Great post from Miko.
>>>> I just have some comments about the "the central focus of SOA is
>>>> missing: upgradeability."
>>>> In Computer Science upgradeability means:
>>>> a. To replace (a software program) with a more recently released,
>>>> enhanced version.
>>>> b. To replace (a hardware device) with one that provides better
>>>> performance.
>>>>
>>>> This is the core advantages of SOA and loosely coupled modules.
>>>> This is also the one of the WS-I goals.
>>>> We cannot achieve it if we use RPC style communication but we can
>>>> achieve it very easily if we use the document style that encapsulates
>>>> the messages and the data.
>>>> With Document style, a change in the structure of a message (like,
>>>> adding a new attribute) does not affect the document exchange mechanisms.
>>>> On the other hand, a change in a back-end (internal) method signature
>>>> has generally no effect upon the messages structure.
>>>> This loose coupling, intrinsic in the Document style, leads to more
>>>> robust and reliable architectures that are easier to maintain, and
>>>> having a modular aspect.
>>>> This is why it is better to design service at a fine-grained and
>>>> composite them together.
>>>> If we do so, we can easily achieve the immutable service and any changes
>>>> will only be done on the composite services, version..etc.
>>>> We will not have any management problems with composite services because
>>>> we can discard any of them and rebuild them from scratch without even
>>>> affect the underlying services.
>>>>
>>>> The resistance from the IT is the among one of the major problems that
>>>> cause and led to SOA failure.
>>>> SOA is a concept and best practice, vendors cannot do more than
>>>> educating and training but the best practice and concept have to be
>>>> followed by someone in the organizations, except if we have the vendor
>>>> take over all the activities from the organizations.
>>>> This is could be done by SaaS / cloud computing but the problem that
>>>> this model will not be successful without having a good SOA
>>>> infrastructure in place.
>>>> IT has to recognize that we have a paradigm shift since 2002 toward
>>>> assembly not development.
>>>> Thank you
>>>>
>>>> Ashraf Galal
>>>>
>>>>
>>>> Gervas Douglas wrote:
>>>>
>>>>> You can read the following article in full at:
>>>>>
>>>>> http://www.infoq.com/articles/soa-governance-revitalized
>>>>>
>>>> <http://www.infoq.com/articles/soa-governance-revitalized>
>>>>
>>>>> Gervas
>>>>>
>>>>> <<The term �SOA Governance� has been used in the industry for years
>>>>> already, but it is still considered an arcane topic. Anyone who reads
>>>>> this article should be able to understand the following things:
>>>>>
>>>>> 1. Why are people pursuing SOA, isn�t it dead?
>>>>> 2. What is the relationship of SOA Governance to SOA itself?
>>>>> 3. What is SOA Governance?
>>>>> 4. How does it differ from Management?
>>>>> 5. How does SOA differ from Integration?
>>>>>
>>>>> While being able to think and speak clearly about these topics may not
>>>>> win you as many brownie points as it would during the time when this
>>>>> was a �hot topic� for Enterprise IT, it will help you understand why
>>>>> SOA and SOA Governance continue to be significant issues for the
>>>>> Enterprise despite the ups and downs of market hype cycles.>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>> (Yahoo! ID required)
>>>>
>>>> service-orientated-architecture-fullfeatured@yahoogroups.com
>>>> <mailto:service-orientated-architecture-fullfeatured@yahoogroups.com>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

Ashraf Galal wrote:
> "Not quite true. If the client side is doing XML schema validation then
> the new attribute will blow their validation based on the old
>
> schema.  This isn't any different from using RPC style and although I'd use
doc/literal for exchange in WS-* I'd still consider it an RPC
> style of communication."
>
> A major problem in adopting RPC style is that, the exchanged XML
> documents cannot be validated against an *XML Schema Definition (XSD).*

I tend to agree with Steve Jones in this regard. Any client that
performs validation over the document received turns the interchange in
a kind of RPC, checking its inputs and failing if one of such inputs is
wrong.

>
> Processes are focused on composition (orchestrating) of services (fine- or
coarse-grained) and discuss in that sense services (fine- or coarse-grained)
become process activities.
>

Composition of services could exist also as a choreography, isn't it?

Regards

Javier Casta��n

Ashraf Galal wrote:

>
> SOA is so valuable to businesses because it enables _process optimization. _
>
> In order to optimize processes, we need to know which processes are
> relevant and we have to understand them - something that _*cannot be
> done */*without business process modeling. */_
>

I have lots of legacy apps working in batch mode. Whenever one
application is going to be demised one, thing I plan to do is to look at
file transfers coming in and out of the soon to be demised application
and then decide which part of the problem is solvable via common data
storage and what part needs to be implemented like services.

A big bang approach where all business processes were analyzed would
take ages to complete.

> There is a major problem with this approach - a semantic gap between the
> process model and the applications.
>
> We need to bridge this gap.
> We need a  a pragmatic approach to business process modeling using the
> Business Process Modeling Notation (BPMN) and the automatic mapping of
> BPMN to the Business Process Execution Language (BPEL), which is the
> de-facto standard for executing business processes in SOA.
>

Perhaps because in the scenario I described I'd be using services as an
strategy for application integration, but otherwise I don't see it as a
good fit for BPMN.

So I don't share the notion that BPMN is absolutely necessary in order
to perform SOA.

Regards

Javier Casta��n

"Not quite true. If the client side is doing XML schema validation then
the new attribute will blow their validation based on the old

schema.  This isn't any different from using RPC style and although I'd use
doc/literal for exchange in WS-* I'd still consider it an RPC
style of communication."

A major problem in adopting RPC style is that, the exchanged XML
documents cannot be validated against an *XML Schema Definition (XSD).*

Let's discuss SOA and BMP:

SOA provides the technology platform for the implementation of business
processes, and the development of applications that provide end-to-end
support for business processes.

Business process modeling for SOA outlines the importance of BPM and its
life-cycle, which consists of business process design, process
implementation, process execution and control, and process optimization.

Modeling business processes for SOA and developing end-to-end IT support for
these processes have become top IT priorities for many organization.

The SOA approach is based on services and on processes.

Processes are focused on composition (orchestrating) of services (fine- or
coarse-grained) and discuss in that sense services (fine- or coarse-grained)
become process activities.

Experience has shown that the implementation and the optimization of
processes are the most important factors in the success of SOA projects.

SOA is so valuable to businesses because it enables _process optimization. _

In order to optimize processes, we need to know which processes are
relevant and we have to understand them - something that _*cannot be
done */*without business process modeling. */_

There is a major problem with this approach - a semantic gap between the
process model and the applications.

We need to bridge this gap.
We need a  a pragmatic approach to business process modeling using the
Business Process Modeling Notation (BPMN) and the automatic mapping of
BPMN to the Business Process Execution Language (BPEL), which is the
de-facto standard for executing business processes in SOA.

We need also to cover related technologies such as Business Rules
Management and Business Activity Monitoring, which play a pivotal role
in achieving closed-loop Business Process Management.

It is true and it is fact and practical if we can change our mind and
think in different way than we got use to think.
Thanks to_ __Matjaz B. Juric
<http://acm.books24x7.com/search.asp?qdom=author&scol=%7Ball%7D&qstr=Matjaz%20B.\
%20Juric>_ and Kapil
Pant
<http://acm.books24x7.com/search.asp?qdom=author&scol=%7Ball%7D&qstr=Kapil%20Pan\
t>


  All the best

Ashraf Galal

Steve Jones wrote:
> 2009/12/8 Ashraf Galal <ashrafwg@...>
>
>>
>> If any changes need to be done in the RPC style, it must affect the
>> server and the clients. There is no doubt about that.
>> For the document style communication, The fact that objects are
>> serialized and deserialized to and from an XML stream, most structural
>> changes can be introduced with zero-impact.
>>
>> For example, in a document/liter wrapped style, we might have a an
>> outcome class that has two attributes: returnMessage and returnCode.
>> There are some consumers who bind to it.
>> We will add a new attribute "other", to it.
>> The server module can now assign a value to the new attribute and the
>> clients that update to the new outcome class can receive that value.
>> But what about the clients who do not update? Well, they will continue
>> to work in the same way.
>> They will obviously not be receiving the new value, but the
>> deserialization process will not break.
>>
>
> Not quite true.  If the client side is doing XML schema validation
> then the new attribute will blow their validation based on the old
> schema.  This isn't any different from using RPC style and although
> I'd use doc/literal for exchange in WS-* I'd still consider it an RPC
> style of communication.
>
>
>> On the other side, we can remove an attribute (for example,
>> returnMessage) in the server module, and have a non-updated client
>> receive a null value in this field, though still working.
>>
>
> Only if it can accept null, if this was a mandatory field then again
> the client will explode.
>
>
>> When we decide to model business processes, that means we takes the
>> business logic out of the application and invoke the applications from
>> the business processes tool. This means refactoring the existing
>> applications, if needed.
>> It is now facts and practical and not theory at all, but we have to
>> understand the pig picture and change the ways that we have got to do
>> the job.
>> It is not an easy task.
>>
>
> BPM tools are applications, just because its in XML doesn't mean it
> isn't code.  I personally am fed up on how people think that BPM tools
> are some sort of magic.  Its plain old Visual COBOL, a nice GUI on a
> process oriented world.  This means it has the same challenges as
> traditional procedural coding systems and I've seem more car crash BPM
> solutions than I care to mention.  Sometimes they are the right
> approach, sometimes they are not the right approach but what ever they
> are they are a TECHNOLOGY platform in which you build TECHNOLOGY
> solutions.
>
> Its not magic, its not a silver bullet.  It can help when used well
> and can destroy projects when used badly.
>
> Steve
>
>
>> All the best
>> Ashraf Galal
>>
>> Michael Poulin wrote:
>>
>>> I am afraid that beside relatively known and trivial facts, the tone
>>> of the statements is a bit orthodoxy...
>>>
>>> For example, "We cannot achieve it [upgradeability] if we use RPC
>>> style communication but we can achieve it very easily if we use the
>>> document style" - it is really impossible to upgrade RPC? I doubt on it.
>>>
>>> This statement is almost revolutionary: "This is why it is better to
>>> design service at a fine-grained and composite them together." As I
>>> recall, the design of services always recommended to consider
>>> coarse-granular approach. Composition of service of absolutely
>>> different granularity targets not just a 'Facade' pattern ( covering
>>> fine-grande interfaces with a coarse-grande one) but creation of
>>> business functionality with new capabilities, IMO.
>>>
>>> "If we do so, we can easily achieve the immutable service and any
>>> changes will only be done on the composite services, version..etc." -
>>> I do not think we may say so because it depends on particular change
>>> in the business environment - some new industry regulations can
>>> affect the very fundamental things implemented in the lowest level of
>>> business services. There is no such thing as 'immutable' for the
>>> entities viewed and operating in the changeable external environment.
>>>
>>> "We will not have any management problems with composite services
>>> because we can discard any of them and rebuild them from scratch
>>> without even
>>> affect the underlying services." - to me this sounds a bit idealistic,
>>> especially when we address management. We have to remember that the
>>> clearance and concrete relationship between the elements of the
>>> technical system do not consider many other aspects that exist in
>>> management, for example. In particular, if you are the owner of the
>>> service composition and want to re-compose it, you are in full power
>>> to 'de-construct' the existing composition but you have to obtain new
>>> permissions to use the old elements /services in the new one (if
>>> you are really in the SO environment). So, for management, this
>>> re-negotiation of use of existing services in new combination may be a
>>> challenge. This is the problem of ownership and management boundaries,
>>> not technical problem.
>>>
>>> I think that the problem with IT with regard to SOA or other
>>> architectural/technological things is in that IT Management assumed it
>>> might decide what to do while this 'role' should belong to Business
>>> and Architecture exclusively. No SaaS/Cloud will help until they
>>> would follow architectural solutions dedicated to resolving concrete
>>> business problems. The major trick here is that technology vendors
>>> cannot properly guess what these problems are in many cases, and they
>>> know about this. Thus, they have to change their appeared from 'we
>>> have the hottest and cool technology available to you(IT)' to
>>> something that fist shows the business value of the product and the
>>> 'cool' part only the second. And this is not that easy and quickly to do.
>>>
>>> - Michael
>>>
>>>
>>>
>>> ----------------------------------------------------------
>>> *From:* Ashraf Galal <ashrafwg@...>
>>> *To:* service-orientated-architecture@yahoogroups.com
>>> *Sent:* Fri, December 4, 2009 5:32:01 AM
>>> *Subject:* Re: [service-orientated-architecture] Miko on SOA Governance
>>>
>>> Another Great post from Miko.
>>> I just have some comments about the "the central focus of SOA is
>>> missing: upgradeability."
>>> In Computer Science upgradeability means:
>>> a. To replace (a software program) with a more recently released,
>>> enhanced version.
>>> b. To replace (a hardware device) with one that provides better
>>> performance.
>>>
>>> This is the core advantages of SOA and loosely coupled modules.
>>> This is also the one of the WS-I goals.
>>> We cannot achieve it if we use RPC style communication but we can
>>> achieve it very easily if we use the document style that encapsulates
>>> the messages and the data.
>>> With Document style, a change in the structure of a message (like,
>>> adding a new attribute) does not affect the document exchange mechanisms.
>>> On the other hand, a change in a back-end (internal) method signature
>>> has generally no effect upon the messages structure.
>>> This loose coupling, intrinsic in the Document style, leads to more
>>> robust and reliable architectures that are easier to maintain, and
>>> having a modular aspect.
>>> This is why it is better to design service at a fine-grained and
>>> composite them together.
>>> If we do so, we can easily achieve the immutable service and any changes
>>> will only be done on the composite services, version..etc.
>>> We will not have any management problems with composite services because
>>> we can discard any of them and rebuild them from scratch without even
>>> affect the underlying services.
>>>
>>> The resistance from the IT is the among one of the major problems that
>>> cause and led to SOA failure.
>>> SOA is a concept and best practice, vendors cannot do more than
>>> educating and training but the best practice and concept have to be
>>> followed by someone in the organizations, except if we have the vendor
>>> take over all the activities from the organizations.
>>> This is could be done by SaaS / cloud computing but the problem that
>>> this model will not be successful without having a good SOA
>>> infrastructure in place.
>>> IT has to recognize that we have a paradigm shift since 2002 toward
>>> assembly not development.
>>> Thank you
>>>
>>> Ashraf Galal
>>>
>>>
>>> Gervas Douglas wrote:
>>>
>>>> You can read the following article in full at:
>>>>
>>>> http://www.infoq.com/articles/soa-governance-revitalized
>>>>
>>> <http://www.infoq.com/articles/soa-governance-revitalized>
>>>
>>>> Gervas
>>>>
>>>> <<The term �SOA Governance� has been used in the industry for years
>>>> already, but it is still considered an arcane topic. Anyone who reads
>>>> this article should be able to understand the following things:
>>>>
>>>> 1. Why are people pursuing SOA, isn�t it dead?
>>>> 2. What is the relationship of SOA Governance to SOA itself?
>>>> 3. What is SOA Governance?
>>>> 4. How does it differ from Management?
>>>> 5. How does SOA differ from Integration?
>>>>
>>>> While being able to think and speak clearly about these topics may not
>>>> win you as many brownie points as it would during the time when this
>>>> was a �hot topic� for Enterprise IT, it will help you understand why
>>>> SOA and SOA Governance continue to be significant issues for the
>>>> Enterprise despite the ups and downs of market hype cycles.>>
>>>>
>>>>
>>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>> (Yahoo! ID required)
>>>
>>> service-orientated-architecture-fullfeatured@yahoogroups.com
>>> <mailto:service-orientated-architecture-fullfeatured@yahoogroups.com>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

2009/12/8 Ashraf Galal <ashrafwg@...>
>
>
>
> If any changes need to be done in the RPC style, it must affect the
> server and the clients. There is no doubt about that.
> For the document style communication, The fact that objects are
> serialized and deserialized to and from an XML stream, most structural
> changes can be introduced with zero-impact.
>
> For example, in a document/liter wrapped style, we might have a an
> outcome class that has two attributes: returnMessage and returnCode.
> There are some consumers who bind to it.
> We will add a new attribute "other", to it.
> The server module can now assign a value to the new attribute and the
> clients that update to the new outcome class can receive that value.
> But what about the clients who do not update? Well, they will continue
> to work in the same way.
> They will obviously not be receiving the new value, but the
> deserialization process will not break.

Not quite true.  If the client side is doing XML schema validation
then the new attribute will blow their validation based on the old
schema.  This isn't any different from using RPC style and although
I'd use doc/literal for exchange in WS-* I'd still consider it an RPC
style of communication.

> On the other side, we can remove an attribute (for example,
> returnMessage) in the server module, and have a non-updated client
> receive a null value in this field, though still working.

Only if it can accept null, if this was a mandatory field then again
the client will explode.

>
> When we decide to model business processes, that means we takes the
> business logic out of the application and invoke the applications from
> the business processes tool. This means refactoring the existing
> applications, if needed.
> It is now facts and practical and not theory at all, but we have to
> understand the pig picture and change the ways that we have got to do
> the job.
> It is not an easy task.

BPM tools are applications, just because its in XML doesn't mean it
isn't code.  I personally am fed up on how people think that BPM tools
are some sort of magic.  Its plain old Visual COBOL, a nice GUI on a
process oriented world.  This means it has the same challenges as
traditional procedural coding systems and I've seem more car crash BPM
solutions than I care to mention.  Sometimes they are the right
approach, sometimes they are not the right approach but what ever they
are they are a TECHNOLOGY platform in which you build TECHNOLOGY
solutions.

Its not magic, its not a silver bullet.  It can help when used well
and can destroy projects when used badly.

Steve

>
> All the best
> Ashraf Galal
>
> Michael Poulin wrote:
> >
> > I am afraid that beside relatively known and trivial facts, the tone
> > of the statements is a bit orthodoxy...
> >
> > For example, "We cannot achieve it [upgradeability] if we use RPC
> > style communication but we can achieve it very easily if we use the
> > document style" - it is really impossible to upgrade RPC? I doubt on it.
> >
> > This statement is almost revolutionary: "This is why it is better to
> > design service at a fine-grained and composite them together." As I
> > recall, the design of services always recommended to consider
> > coarse-granular approach. Composition of service of absolutely
> > different granularity targets not just a 'Facade' pattern ( covering
> > fine-grande interfaces with a coarse-grande one) but creation of
> > business functionality with new capabilities, IMO.
> >
> > "If we do so, we can easily achieve the immutable service and any
> > changes will only be done on the composite services, version..etc." -
> > I do not think we may say so because it depends on particular change
> > in the business environment - some new industry regulations can
> > affect the very fundamental things implemented in the lowest level of
> > business services. There is no such thing as 'immutable' for the
> > entities viewed and operating in the changeable external environment.
> >
> > "We will not have any management problems with composite services
> > because we can discard any of them and rebuild them from scratch
> > without even
> > affect the underlying services." - to me this sounds a bit idealistic,
> > especially when we address management. We have to remember that the
> > clearance and concrete relationship between the elements of the
> > technical system do not consider many other aspects that exist in
> > management, for example. In particular, if you are the owner of the
> > service composition and want to re-compose it, you are in full power
> > to 'de-construct' the existing composition but you have to obtain new
> > permissions to use the old elements /services in the new one (if
> > you are really in the SO environment). So, for management, this
> > re-negotiation of use of existing services in new combination may be a
> > challenge. This is the problem of ownership and management boundaries,
> > not technical problem.
> >
> > I think that the problem with IT with regard to SOA or other
> > architectural/technological things is in that IT Management assumed it
> > might decide what to do while this 'role' should belong to Business
> > and Architecture exclusively. No SaaS/Cloud will help until they
> > would follow architectural solutions dedicated to resolving concrete
> > business problems. The major trick here is that technology vendors
> > cannot properly guess what these problems are in many cases, and they
> > know about this. Thus, they have to change their appeared from 'we
> > have the hottest and cool technology available to you(IT)' to
> > something that fist shows the business value of the product and the
> > 'cool' part only the second. And this is not that easy and quickly to do.
> >
> > - Michael
> >
> >
> >
> > ----------------------------------------------------------
> > *From:* Ashraf Galal <ashrafwg@...>
> > *To:* service-orientated-architecture@yahoogroups.com
> > *Sent:* Fri, December 4, 2009 5:32:01 AM
> > *Subject:* Re: [service-orientated-architecture] Miko on SOA Governance
> >
> > Another Great post from Miko.
> > I just have some comments about the "the central focus of SOA is
> > missing: upgradeability."
> > In Computer Science upgradeability means:
> > a. To replace (a software program) with a more recently released,
> > enhanced version.
> > b. To replace (a hardware device) with one that provides better
> > performance.
> >
> > This is the core advantages of SOA and loosely coupled modules.
> > This is also the one of the WS-I goals.
> > We cannot achieve it if we use RPC style communication but we can
> > achieve it very easily if we use the document style that encapsulates
> > the messages and the data.
> > With Document style, a change in the structure of a message (like,
> > adding a new attribute) does not affect the document exchange mechanisms.
> > On the other hand, a change in a back-end (internal) method signature
> > has generally no effect upon the messages structure.
> > This loose coupling, intrinsic in the Document style, leads to more
> > robust and reliable architectures that are easier to maintain, and
> > having a modular aspect.
> > This is why it is better to design service at a fine-grained and
> > composite them together.
> > If we do so, we can easily achieve the immutable service and any changes
> > will only be done on the composite services, version..etc.
> > We will not have any management problems with composite services because
> > we can discard any of them and rebuild them from scratch without even
> > affect the underlying services.
> >
> > The resistance from the IT is the among one of the major problems that
> > cause and led to SOA failure.
> > SOA is a concept and best practice, vendors cannot do more than
> > educating and training but the best practice and concept have to be
> > followed by someone in the organizations, except if we have the vendor
> > take over all the activities from the organizations.
> > This is could be done by SaaS / cloud computing but the problem that
> > this model will not be successful without having a good SOA
> > infrastructure in place.
> > IT has to recognize that we have a paradigm shift since 2002 toward
> > assembly not development.
> > Thank you
> >
> > Ashraf Galal
> >
> >
> > Gervas Douglas wrote:
> > >
> > > You can read the following article in full at:
> > >
> > > http://www.infoq.com/articles/soa-governance-revitalized
> > <http://www.infoq.com/articles/soa-governance-revitalized>
> > >
> > > Gervas
> > >
> > > <<The term �SOA Governance� has been used in the industry for years
> > > already, but it is still considered an arcane topic. Anyone who reads
> > > this article should be able to understand the following things:
> > >
> > > 1. Why are people pursuing SOA, isn�t it dead?
> > > 2. What is the relationship of SOA Governance to SOA itself?
> > > 3. What is SOA Governance?
> > > 4. How does it differ from Management?
> > > 5. How does SOA differ from Integration?
> > >
> > > While being able to think and speak clearly about these topics may not
> > > win you as many brownie points as it would during the time when this
> > > was a �hot topic� for Enterprise IT, it will help you understand why
> > > SOA and SOA Governance continue to be significant issues for the
> > > Enterprise despite the ups and downs of market hype cycles.>>
> > >
> > >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> > (Yahoo! ID required)
> >
> > service-orientated-architecture-fullfeatured@yahoogroups.com
> > <mailto:service-orientated-architecture-fullfeatured@yahoogroups.com>
> >
> >
> >
> >
>
>

If any changes need to be done in the RPC style, it must affect the
server and the clients.  There is no doubt about that.
For the document style communication, The fact that objects are
serialized and deserialized to and from an XML stream, most structural
changes can be introduced with zero-impact.

For example, in a document/liter wrapped style, we might have a an
outcome class that has two attributes: returnMessage and returnCode.
There are some consumers who bind to it.
We will add a new attribute "other", to it.
The server module can now assign a value to the new attribute and the
clients that update to the new outcome class can receive that value.
But what about the clients who do not update? Well, they will continue
to work in the same way.
They will obviously not be receiving the new value, but the
deserialization process will not break.
On the other side, we can remove an attribute (for example,
returnMessage) in the server module, and have a non-updated client
receive a null value in this field, though still working.

When we decide to  model business processes, that means we takes the
business logic out of the application and invoke the applications from
the business processes tool. This means refactoring the existing
applications, if needed.
It is now facts and practical and not theory at all, but we have to
understand the pig picture and change the ways that we have got to do
the job.
It is not an easy task.

All the best
Ashraf Galal


Michael Poulin wrote:
>
> I am afraid that beside relatively known and trivial facts, the tone
> of the statements is a bit orthodoxy...
>
> For example, "We cannot achieve it [upgradeability] if we use RPC
> style communication but we can achieve it very easily if we use the
> document style" - it is really impossible to upgrade RPC? I doubt on it.
>
> This statement is almost revolutionary: "This is why it is better to
> design service at a fine-grained and composite them together." As I
> recall, the design of services always recommended to consider
> coarse-granular approach. Composition of service of absolutely
> different granularity targets not just a 'Facade' pattern ( covering
> fine-grande  interfaces with a coarse-grande one) but creation of
> business functionality with new capabilities, IMO.
>
> "If we do so, we can easily achieve the immutable service and any
> changes will only be done on the composite services, version..etc." -
> I do not think we may say so because it depends on particular change
> in the business environment  - some new industry regulations can
> affect the very fundamental things implemented in the lowest level of
> business services. There is no such thing as 'immutable' for the
> entities viewed and operating in the changeable external environment.
>
> "We will not have any management problems with composite services
> because we can discard any of them and rebuild them from scratch
> without even
> affect the underlying services." - to me this sounds a bit idealistic,
> especially when we address management. We have to remember that the
> clearance and concrete relationship between the elements of the
> technical system do not consider many other aspects that exist in
> management, for example. In particular, if you are the owner of the
> service composition and want to re-compose it, you are in full power
> to 'de-construct' the existing composition but you have to obtain new
> permissions to use the old elements /services in the new one (if
> you are really in the SO environment). So, for management, this
> re-negotiation of use of existing services in new combination may be a
> challenge. This is the problem of ownership and management boundaries,
> not technical problem.
>
> I think that the problem with IT  with regard to SOA or other
> architectural/technological things is in that IT Management assumed it
> might decide what to do while this 'role' should belong to Business
> and Architecture exclusively. No SaaS/Cloud will help  until they
> would follow architectural solutions dedicated to resolving concrete
> business problems. The major trick here is that technology vendors
> cannot properly guess what these problems are in many cases, and they
> know about this. Thus, they have to change their appeared from 'we
> have the hottest and cool technology available to you(IT)' to
> something that fist shows the business value of the product and the
> 'cool' part only the second. And this is not that easy and quickly to do.
>
> - Michael
>
>
>
> ------------------------------------------------------------------------
> *From:* Ashraf Galal <ashrafwg@...>
> *To:* service-orientated-architecture@yahoogroups.com
> *Sent:* Fri, December 4, 2009 5:32:01 AM
> *Subject:* Re: [service-orientated-architecture] Miko on SOA Governance
>
> Another Great post from Miko.
> I just have some comments about the "the central focus of SOA is
> missing: upgradeability."
> In Computer Science upgradeability means:
> a. To replace (a software program) with a more recently released,
> enhanced version.
> b. To replace (a hardware device) with one that provides better
> performance.
>
> This is the core advantages of SOA and loosely coupled modules.
> This is also the one of the WS-I goals.
> We cannot achieve it if we use RPC style communication but we can
> achieve it very easily if we use the document style that encapsulates
> the messages and the data.
> With Document style, a change in the structure of a message (like,
> adding a new attribute) does not affect the document exchange mechanisms.
> On the other hand, a change in a back-end (internal) method signature
> has generally no effect upon the messages structure.
> This loose coupling, intrinsic in the Document style, leads to more
> robust and reliable architectures that are easier to maintain, and
> having a modular aspect.
> This is why it is better to design service at a fine-grained and
> composite them together.
> If we do so, we can easily achieve the immutable service and any changes
> will only be done on the composite services, version..etc.
> We will not have any management problems with composite services because
> we can discard any of them and rebuild them from scratch without even
> affect the underlying services.
>
> The resistance from the IT is the among one of the major problems that
> cause and led to SOA failure.
> SOA is a concept and best practice, vendors cannot do more than
> educating and training but the best practice and concept have to be
> followed by someone in the organizations, except if we have the vendor
> take over all the activities from the organizations.
> This is could be done by SaaS / cloud computing but the problem that
> this model will not be successful without having a good SOA
> infrastructure in place.
> IT has to recognize that we have a paradigm shift since 2002 toward
> assembly not development.
> Thank you
>
> Ashraf Galal
>
>
> Gervas Douglas wrote:
> >
> > You can read the following article in full at:
> >
> > http://www.infoq.com/articles/soa-governance-revitalized
> <http://www.infoq.com/articles/soa-governance-revitalized>
> >
> > Gervas
> >
> > <<The term “SOA Governance” has been used in the industry for years
> > already, but it is still considered an arcane topic. Anyone who reads
> > this article should be able to understand the following things:
> >
> >    1. Why are people pursuing SOA, isn’t it dead?
> >    2. What is the relationship of SOA Governance to SOA itself?
> >    3. What is SOA Governance?
> >    4. How does it differ from Management?
> >    5. How does SOA differ from Integration?
> >
> > While being able to think and speak clearly about these topics may not
> > win you as many brownie points as it would during the time when this
> > was a “hot topic” for Enterprise IT, it will help you understand why
> > SOA and SOA Governance continue to be significant issues for the
> > Enterprise despite the ups and downs of market hype cycles.>>
> >
> >
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>     (Yahoo! ID required)
>
>     service-orientated-architecture-fullfeatured@yahoogroups.com
> <mailto:service-orientated-architecture-fullfeatured@yahoogroups.com>
>
>
>
>

Another Great post from Miko.
I just have some comments about the "the central focus of SOA is
missing: upgradeability."
In Computer Science upgradeability means:
a. To replace (a software program) with a more recently released,
enhanced version.
b. To replace (a hardware device) with one that provides better performance.

This is the core advantages of SOA and loosely coupled modules.
This is also the one of the WS-I goals.
We cannot achieve it if we use RPC style communication but we can
achieve it very easily if we use the document style that encapsulates
the messages and the data.
With Document style, a change in the structure of a message (like,
adding a new attribute) does not affect the document exchange mechanisms.
On the other hand, a change in a back-end (internal) method signature
has generally no effect upon the messages structure.
This loose coupling, intrinsic in the Document style, leads to more
robust and reliable architectures that are easier to maintain, and
having a modular aspect.
This is why it is better to design service at a fine-grained and
composite them together.
If we do so, we can easily achieve the immutable service and any changes
will only be done on the composite services, version..etc.
We will not have any management problems with composite services because
we can discard any of them and rebuild them from scratch without even
affect the underlying services.

The resistance from the IT is the among one of the major problems that
cause and led to SOA failure.
SOA is a concept and best practice, vendors cannot do more than
educating and training but the best practice and concept have to be
followed by someone in the organizations, except if we have the vendor
take over all the activities from the organizations.
This is could be done by SaaS / cloud computing but the problem that
this model will not be successful without having a good SOA
infrastructure in place.
IT has to recognize that we have a paradigm shift since 2002 toward
assembly not development.
Thank you

Ashraf Galal


Gervas Douglas wrote:
>
> You can read the following article in full at:
>
> http://www.infoq.com/articles/soa-governance-revitalized
>
> Gervas
>
> <<The term �SOA Governance� has been used in the industry for years
> already, but it is still considered an arcane topic. Anyone who reads
> this article should be able to understand the following things:
>
>    1. Why are people pursuing SOA, isn�t it dead?
>    2. What is the relationship of SOA Governance to SOA itself?
>    3. What is SOA Governance?
>    4. How does it differ from Management?
>    5. How does SOA differ from Integration?
>
> While being able to think and speak clearly about these topics may not
> win you as many brownie points as it would during the time when this
> was a �hot topic� for Enterprise IT, it will help you understand why
> SOA and SOA Governance continue to be significant issues for the
> Enterprise despite the ups and downs of market hype cycles.>>
>
>

1. Why are people pursuing SOA, isn’t it dead?
2. What is the relationship of SOA Governance to SOA itself?
3. What is SOA Governance?
4. How does it differ from Management?
5. How does SOA differ from Integration?

While being able to think and speak clearly about these topics may not win you as many brownie points as it would during the time when this was a “hot topic” for Enterprise IT, it will help you understand why SOA and SOA Governance continue to be significant issues for the Enterprise despite the ups and downs of market hype cycles.>>

--- In service-orientated-architecture@yahoogroups.com, "Gervas"
<gervas.douglas@...> wrote:
>
> You might find this Q&A on the subject of interest:
http://tech.groups.yahoo.com/group/n-gaa/message/1130
>
> What do you think of its relevance to SOA?

More specifically do you think it could usefully be used to break down data
silos?

Gervas

>
> Gervas
>

You might find this Q&A on the subject of interest:
http://tech.groups.yahoo.com/group/n-gaa/message/1130

What do you think of its relevance to SOA?

Gervas

The book "SOA Governance achieving and sustaining business and it
agility" by Willim Brown, Robert Laird, Clive Gee and Tilak Mitra. IBM press
Is deserve the time to read too. It has nothing to say about IBM
products at all.
It just about the process.
All the best

Ashraf Galal
Gervas Douglas wrote:
>
> *You can read the following article in full at:
>
> http://www.infoq.com/articles/poulin-wonderland-soa-governance
>
> Gervas*
>
> <<One man, Harry W., once said "/Alice// does not fall down the hole.
> She sees the white //rabbit, is intrigued, and willingly follows him
> down the deep rabbit hole/." Yes, the secret of Wonderland is about
> the meaning of the words: Harry has insisted that Alice �/willingly
> follow[s]�/ into the Rabbit Hole while Alice has certainly �/found
> herself falling down
>
<http://www.amazon.co.uk/Alice-Wonderland-Pop-up-Lewis-Carroll/dp/0689837593/ref\
=sr_l_l?ie=UTF8&s=books&qid=1252961769&sr=8-l>/�.
> The same happens with SOA Governance � like in the Rabbit Hole, one
> thinks about governance but talks about management and another one
> does the exact opposite...
>
> We used to think that management includes governance. This is correct
> understanding: Oxford and Merriam-Webster dictionaries as well as
> English Synonym Dictionary <http://dico.isc.cnrs.fr/dico/en/search>
> include 'governance' as a remote synonym to 'management'. However, the
> opposite is not true -governance is not management. Governance is
> about policies and controlling riles while management is about policy
> execution and controls. Management needs governance because without
> governance it does not know what and how to run, execute or preserve.
>
> I am aware of at least 3 books written about SOA Governance and at
> least 8 articles published only in infoQ
> <http://www.infoq.com/governance> on this topic in the last two years.
> Nonetheless, I have found that in absolute majority of publications
> about SOA Governance it is directly associated with policy enforcement
> or with a straightforward management. To date, only OASIS SOA
> Reference Architecture (RA), Public Review Draft 1
> <http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf>
> recognises the effect of the 'rabbit hole' and clearly separates
> governance of service-oriented environment from its management
> <http://www.infoq.com/news/2008/08/poulin-governance>.>>
>
>

<<OASIS SOA technical Committee has published the second Public Review Draft of SOA Reference Architecture now under the refined title 'Public Review of Reference Architecture Foundation for SOA v1.0'

This review has a lot of updates and new content with regard to the first Public Review Draft published last year. This Draft has a 'Navigating the SOA Standards Landscape Around Architecture' in its background - the collaboration agreement on SOA standard efforts between OASIS, OMG and The Open Group.

Also, this Draft contains several outstanding statements that are very important to the understanding of modern state of service-oriented architecture and service orientation at large. For example, the Abstract says: "Our focus in this architecture is on an approach to integrating business with the information technology needed to support it."

This statement is supported by OASIS conclusion that "Service Oriented Architecture (SOA) is an architectural paradigm that has gained significant attention within the information technology (IT) and business communities. The SOA ecosystem described in this document occupies the boundary between business and IT. It is neither wholly IT nor wholly business, but is of both worlds. Neither business nor IT completely own, govern and manage this SOA ecosystem. Both sets of concerns must be accommodated for the SOA ecosystem to fulfill its purposes."

You are all welcome to Modern SOA!>>

You can read this at: http://www.ebizq.net/blogs/service_oriented/2009/11/new_soa_standard_public_review_draft.php

Gervas

<<One man, Harry W., once said "Alice does not fall down the hole. She sees the white rabbit, is intrigued, and willingly follows him down the deep rabbit hole." Yes, the secret of Wonderland is about the meaning of the words: Harry has insisted that Alice ‘willingly follow[s]’ into the Rabbit Hole while Alice has certainly “found herself falling down”. The same happens with SOA Governance – like in the Rabbit Hole, one thinks about governance but talks about management and another one does the exact opposite...

We used to think that management includes governance. This is correct understanding: Oxford and Merriam-Webster dictionaries as well as English Synonym Dictionary include 'governance' as a remote synonym to 'management'. However, the opposite is not true -governance is not management. Governance is about policies and controlling riles while management is about policy execution and controls. Management needs governance because without governance it does not know what and how to run, execute or preserve.

I am aware of at least 3 books written about SOA Governance and at least 8 articles published only in infoQ on this topic in the last two years. Nonetheless, I have found that in absolute majority of publications about SOA Governance it is directly associated with policy enforcement or with a straightforward management. To date, only OASIS SOA Reference Architecture (RA), Public Review Draft 1 recognises the effect of the 'rabbit hole' and clearly separates governance of service-oriented environment from its management.>>

Governance is different than management.
Governance is not charged with implementing the SOA.
Governance provides oversight to see that SOA is accomplished in a
manner that satisfies the principles and policies required to
successfully and continually sustain the SOA environment.
There are different kind of governances in an enterprise starting with
Enterprise governance, then IT governance then SOA governance that
extends IT governance.
The best definition of SOA that incorporate the definition of SOA
governance is from OASIS, SOA reference model one
(www.oasis-open.org/home/index.php)
Although the management and governance overlapped with each other, but I
think it is better to distinguish between SOA implementation or
management than SOA governance.

All the best

Ashraf Galal

rschmelzer wrote:
>
>
>     The Four Stages of SOA Governance
>
>
>         Document ID: ZAPFLASH-20091112 | Document Type: ZapFlash
>         By: /Jason Bloomberg/ | Posted: /Nov. 12, 2009/
>
>
> For several years now, ZapThink has spoken about SOA Governance "in
> the narrow" vs. SOA governance "in the broad." SOA governance in the
> narrow refers to governance of the SOA initiative, and focuses
> primarily on the Service lifecycle. When vendors try to sell you SOA
> governance gear, they're typically talking about SOA governance in the
> narrow. SOA governance in the broad, in contrast, refers to IT
> governance in the SOA context. In other words, how will SOA help with
> IT governance (and by extension, corporate governance) once your SOA
> initiative is up and running?
>
> In both our Licensed ZapThink Architect Boot Camp
> <http://t.ymlp38.com/hqjmazaebbaxauybhalaemss/click.php> as well as
> our newer SOA and Cloud Governance Course
> <http://t.ymlp38.com/hqjjataebbarauybhafaemss/click.php>, we also
> point out how governance typically involves human
> communication-centric activities like architecture reviews, human
> management, and people deciding to comply with policies. We point out
> this human context for governance to contrast it to the technology
> context that inevitably becomes the focus of SOA governance in the
> narrow. There is an important technology-centric SOA governance story
> to be told, of course, as long as it's placed into the greater
> governance context.
>
> One question we haven't yet addressed in depth, however, is how these
> two contrasts -- narrow vs. broad, human vs. technology -- fit
> together. Taking a closer look, there's an important trend taking
> shape, as organizations mature their approach to SOA governance, and
> with it, the overall SOA effort. Following this trend to its natural
> conclusion highlights some important facts about SOA, and can help
> organizations understand where they want to end up as their SOA
> initiative reaches its highest levels of maturity.
>
> *Introducing the SOA Governance Grid*
> Whenever faced with to orthogonal contrasts, the obvious thing to do
> is put them in a grid. Let's see what we can learn from such a diagram:
>
> *The ZapThink SOA Governance Grid*
>
> First, let's take a look at what each square contains, starting with
> the lower left corner and moving clockwise, because as we'll see,
> that's the sequence that corresponds best to increasing levels of SOA
> maturity.
>
>    1. Human-centric SOA governance in the narrow
>
>       As organizations first look at SOA and the governance challenge
>       it presents, they must decide how they want to handle various
>       governance issues. They must set up a SOA governance board or
>       other committee to make broad SOA policy decisions. We also
>       recommend setting up a SOA Center of Excellence to coordinate
>       such policies across the whole enterprise. These policy
>       decisions initially focus on how to address business
>       requirements, how to assemble and coordinate the SOA team, and
>       what the team will need to do as they ramp up the SOA effort.
>       The output of such SOA governance activities tend to be written
>       documents and plenty of conversations and meetings.
>
>       The tools architects use for this stage are primarily
>       communication-centric, namely word processors and portals and
>       the like. But this stage is also when the repository comes into
>       play as a place to put many such design time artifacts, and also
>       where architects configure design time workflows for the SOA
>       team. Technology, however, plays only a supporting role in this
>       stage.
>
>    2. Technology-centric SOA governance in the narrow
>
>       As the SOA effort ramps up, the focus naturally shifts to
>       technology. Governance activities center on the
>       registry/repository and the rest of the SOA governance gear.
>       Architects roll up their sleeves and hammer out
>       technology-centric policies, preferably in an XML format that
>       the gear can understand. Representing certain policies as
>       metadata enables automated communication and enforcement of
>       those policies, and also makes it more straightforward to change
>       those policies over time.
>
>       This stage is also when run time SOA governance begins. Certain
>       policies must be enforced at run time, either within the
>       underlying runtime environment, in the management tool, or in
>       the security infrastructure. At this point the SOA registry
>       becomes a central governance tool, because it provides a single
>       discovery point for run time policies. Tool-based
>       interoperability also rises to the fore, as WS-I compliance, as
>       well as compliance with the Governance Interoperability
>       Framework
>       <http://t.ymlp38.com/hqjbazaebbaxauybhataemss/click.php> or the
>       CentraSite Community
>       <http://t.ymlp38.com/hqjhalaebbapauybhavaemss/click.php> become
>       essential governance policies.
>
>    3. Technology-centric SOA governance in the broad
>
>       The SOA implementation is up and running. There are a number of
>       Services in production, and their lifecycle is fully governed
>       through hard work and proper architectural planning. Taking the
>       SOA approach to responding to new business requirements is
>       becoming the norm. So, when new requirements mean new policies,
>       it's possible to represent some of them as metadata as well,
>       even though the policies aren't specific to SOA. Such policies
>       are still technology-centric, for example, security policies or
>       data governance policies or the like. Fortunately, the SOA
>       governance infrastructure is up to the task of managing,
>       communicating, and coordinating the enforcement of such
>       policies. By leveraging SOA, it's possible to centralize policy
>       creation and communication, even for policies that aren't
>       SOA-specific.
>
>       Sometimes, in fact, new governance requirements can best be met
>       with new Services. For example, a new regulatory requirement
>       might lead to a new message auditing policy. Why not build a
>       Service to take care of that? This example highlights what we
>       mean by SOA governance in the broad. SOA is in place, so when a
>       new governance requirement comes over the wall, we naturally
>       leverage SOA to meet that requirement.
>
>    4. Human-centric SOA governance in the broad
>
>       This final stage is the most thought-provoking of all, because
>       it represents the highest maturity level. How can SOA help with
>       the human activities that form the larger picture of governance
>       in the organization? Clearly, XML representations of technical
>       policies aren't the answer here. Rather, it's how implementing
>       SOA helps expand the governance role architecture plays in the
>       organization. It's a core best practice that architecture should
>       drive IT governance. When the organization has adopted SOA, then
>       SOA helps to inform best practices for IT governance overall.
>
>       The impact of SOA on Enterprise Architecture (EA) is also quite
>       significant. Now that EAs increasingly realize that SOA is a
>       style of EA, EA governance is becoming increasingly
>       Service-oriented in form as well. It is at this stage that part
>       of the SOA governance value proposition benefits the business
>       directly, by formalizing how the enterprise represents
>       capabilities consistent with the priorities of the organization.
>
> *The ZapThink Take*
> The big win to moving to the fourth stage is in how leveraging SOA
> approaches to formalize EA governance impacts the organization's
> business agility requirement. In some ways business agility is like
> any other business requirement, in that proper business analysis can
> delineate the requirement to the point that the technology team can
> deliver it, the quality team can test for it, and the infrastructure
> can enforce it. But as we've written before
> <http://t.ymlp38.com/hqjwaiaebbaxauybhacaemss/click.php>, as an
> emergent property of the implementation, business agility is a
> different sort of requirement from more traditional business
> requirements in a fundamental way.
>
> A critical part of achieving this business agility over time is to
> break down the business agility requirement into a set of policies,
> and then establish, communicate, and enforce those policies -- in
> other words, provide business agility governance. Only now, we're not
> talking about technology at all. We're talking about transforming how
> the organization leverages resources in a more agile manner by
> formalizing its approach to governance by following SOA best practices
> at the EA level. Organizations must understand the role SOA governance
> plays in achieving this long-term strategic vision for the enterprise.
>
>

The Four Stages of SOA Governance

Document ID: ZAPFLASH-20091112 | Document Type: ZapFlash
By: Jason Bloomberg | Posted: Nov. 12, 2009

For several years now, ZapThink has spoken about SOA Governance "in the narrow" vs. SOA governance "in the broad." SOA governance in the narrow refers to governance of the SOA initiative, and focuses primarily on the Service lifecycle. When vendors try to sell you SOA governance gear, they're typically talking about SOA governance in the narrow. SOA governance in the broad, in contrast, refers to IT governance in the SOA context. In other words, how will SOA help with IT governance (and by extension, corporate governance) once your SOA initiative is up and running?

In both our Licensed ZapThink Architect Boot Camp as well as our newer SOA and Cloud Governance Course, we also point out how governance typically involves human communication-centric activities like architecture reviews, human management, and people deciding to comply with policies. We point out this human context for governance to contrast it to the technology context that inevitably becomes the focus of SOA governance in the narrow. There is an important technology-centric SOA governance story to be told, of course, as long as it's placed into the greater governance context.

One question we haven't yet addressed in depth, however, is how these two contrasts -- narrow vs. broad, human vs. technology -- fit together. Taking a closer look, there's an important trend taking shape, as organizations mature their approach to SOA governance, and with it, the overall SOA effort. Following this trend to its natural conclusion highlights some important facts about SOA, and can help organizations understand where they want to end up as their SOA initiative reaches its highest levels of maturity.

Introducing the SOA Governance Grid
Whenever faced with to orthogonal contrasts, the obvious thing to do is put them in a grid. Let's see what we can learn from such a diagram:

The ZapThink SOA Governance Grid

First, let's take a look at what each square contains, starting with the lower left corner and moving clockwise, because as we'll see, that's the sequence that corresponds best to increasing levels of SOA maturity.

1. Human-centric SOA governance in the narrow

   As organizations first look at SOA and the governance challenge it presents, they must decide how they want to handle various governance issues. They must set up a SOA governance board or other committee to make broad SOA policy decisions. We also recommend setting up a SOA Center of Excellence to coordinate such policies across the whole enterprise. These policy decisions initially focus on how to address business requirements, how to assemble and coordinate the SOA team, and what the team will need to do as they ramp up the SOA effort. The output of such SOA governance activities tend to be written documents and plenty of conversations and meetings.

   The tools architects use for this stage are primarily communication-centric, namely word processors and portals and the like. But this stage is also when the repository comes into play as a place to put many such design time artifacts, and also where architects configure design time workflows for the SOA team. Technology, however, plays only a supporting role in this stage.

2. Technology-centric SOA governance in the narrow

   As the SOA effort ramps up, the focus naturally shifts to technology. Governance activities center on the registry/repository and the rest of the SOA governance gear. Architects roll up their sleeves and hammer out technology-centric policies, preferably in an XML format that the gear can understand. Representing certain policies as metadata enables automated communication and enforcement of those policies, and also makes it more straightforward to change those policies over time.

   This stage is also when run time SOA governance begins. Certain policies must be enforced at run time, either within the underlying runtime environment, in the management tool, or in the security infrastructure. At this point the SOA registry becomes a central governance tool, because it provides a single discovery point for run time policies. Tool-based interoperability also rises to the fore, as WS-I compliance, as well as compliance with the Governance Interoperability Framework or the CentraSite Community become essential governance policies.

3. Technology-centric SOA governance in the broad

   The SOA implementation is up and running. There are a number of Services in production, and their lifecycle is fully governed through hard work and proper architectural planning. Taking the SOA approach to responding to new business requirements is becoming the norm. So, when new requirements mean new policies, it's possible to represent some of them as metadata as well, even though the policies aren't specific to SOA. Such policies are still technology-centric, for example, security policies or data governance policies or the like. Fortunately, the SOA governance infrastructure is up to the task of managing, communicating, and coordinating the enforcement of such policies. By leveraging SOA, it's possible to centralize policy creation and communication, even for policies that aren't SOA-specific.

   Sometimes, in fact, new governance requirements can best be met with new Services. For example, a new regulatory requirement might lead to a new message auditing policy. Why not build a Service to take care of that? This example highlights what we mean by SOA governance in the broad. SOA is in place, so when a new governance requirement comes over the wall, we naturally leverage SOA to meet that requirement.

4. Human-centric SOA governance in the broad

   This final stage is the most thought-provoking of all, because it represents the highest maturity level. How can SOA help with the human activities that form the larger picture of governance in the organization? Clearly, XML representations of technical policies aren't the answer here. Rather, it's how implementing SOA helps expand the governance role architecture plays in the organization. It's a core best practice that architecture should drive IT governance. When the organization has adopted SOA, then SOA helps to inform best practices for IT governance overall.

   The impact of SOA on Enterprise Architecture (EA) is also quite significant. Now that EAs increasingly realize that SOA is a style of EA, EA governance is becoming increasingly Service-oriented in form as well. It is at this stage that part of the SOA governance value proposition benefits the business directly, by formalizing how the enterprise represents capabilities consistent with the priorities of the organization.

The ZapThink Take
The big win to moving to the fourth stage is in how leveraging SOA approaches to formalize EA governance impacts the organization's business agility requirement. In some ways business agility is like any other business requirement, in that proper business analysis can delineate the requirement to the point that the technology team can deliver it, the quality team can test for it, and the infrastructure can enforce it. But as we've written before, as an emergent property of the implementation, business agility is a different sort of requirement from more traditional business requirements in a fundamental way.

A critical part of achieving this business agility over time is to break down the business agility requirement into a set of policies, and then establish, communicate, and enforce those policies -- in other words, provide business agility governance. Only now, we're not talking about technology at all. We're talking about transforming how the organization leverages resources in a more agile manner by formalizing its approach to governance by following SOA best practices at the EA level. Organizations must understand the role SOA governance plays in achieving this long-term strategic vision for the enterprise.

http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper

---- Begin Extract -----
Today, HTTP and TCP are the protocols of the web.  TCP is the generic,
reliable transport protocol, providing guaranteed delivery, duplicate
suppression, in-order delivery, flow control, congestion avoidance and
other transport features.  HTTP is the application level protocol
providing basic request/response semantics. While we believe that
there may be opportunities to improve latency at the transport layer,
our initial investigations have focussed on the application layer,
HTTP.

Unfortunately, HTTP was not particularly designed for latency.
Furthermore, the web pages transmitted today are significantly
different from web pages 10 years ago such and demand improvements to
HTTP that could not have been anticipated when HTTP was developed. The
following are some of the features of HTTP that inhibit optimal
performance:

     * Single request per connection. Because HTTP can only fetch one
resource at a time (HTTP pipelining helps, but still enforces only a
FIFO queue), a server delay of 500 ms prevents reuse of the TCP
channel for additional requests.  Browsers work around this problem by
using multiple connections.  Since 2008, most browsers have finally
moved from 2 connections per domain to 6.
     * Exclusively client-initiated requests. In HTTP, only the client
can initiate a request. Even if the server knows the client needs a
resource, it has no mechanism to inform the client and must instead
wait to receive a request for the resource from the client.
     * Uncompressed request and response headers. Request headers today
vary in size from ~200 bytes to over 2KB.  As applications use more
cookies and user agents expand features, typical header sizes of
700-800 bytes is common. For modems or ADSL connections, in which the
uplink bandwidth is fairly low, this latency can be significant.
Reducing the data in headers could directly improve the serialization
latency to send requests.
     * Redundant headers. In addition, several headers are repeatedly
sent across requests on the same channel. However, headers such as the
User-Agent, Host, and Accept* are generally static and do not need to
be resent.
     * Optional data compression. HTTP uses optional compression
encodings for data. Content should always be sent in a compressed
format.
---- End Extract ----

Now it still says its using the HTTP methods so I'd guess its still
"REST" compliant, the main differences being that with the server
pushing information to the client it might break some of those
"stateless" pieces.

Its good to see people taking the latency problem seriously and
looking for a fix.

Steve

Where you start from is important, says Steve Jones, a CTO at consultancy CapGemini in the U.K. Out-of-the-gate understanding of the roles of services and process steps is part of that. Jones suggests starting with a SOA-oriented approach. But the tenor of that approach is key. If it is utterly technology-centric, the BPM-SOA project is likely to stumble. Jones encourages a SOA approach that is grounded in business understanding.

''SOA for us is a business thing,'' said Jones. ''It is a way of modeling the business, thinking about the business and understanding the business.''

On one level, there are similarities to BPM and SOA approaches.

''If you think about an organization at its highest level, whether you are looking at high-level BPM models or at a services methodology, you actually end up with the same bundles.''

A business-oriented approach to SOA can help BPM, suggested Jones.

''Using SOA as we do—as an architecture and business modeling approach—helps bridge the gap between traditional business process modeling and technology delivery,'' he said.

Where it becomes most interesting is where there are "steps." This is where BPM that has little SOA underpinning can go astray. When a process is seen as something contained in a service, better outcomes ensue.

Said Jones, ''Where SOA becomes really required is where BPM has a number of steps. We would say that it is the service that is always the 'grown' in the relationship. It contains the processes - the capabilities that need to be delivered.''

It is BPM's job to build process steps; it is the service model's job to access them, he indicated.

In short, in Jones' view: ''SOA makes really, really good BPM. But BPM bakes really bad SOA.''>>

You can find this article at: http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1374106,00.html#

Gervas

I can provide you with my dissertation that I wrote it 2007, if you want.
The purpose was to clarifying the concept and compare the two
architectural styles WS-* and REST and it accompanied with  a prototype
that you can follow it and implement it to tie the architectural concept
to the implementation techniques.
I do believe it is a very simple architectural concept and easier to
grasp and understand better than any other architectures.
All the best

Ashraf Galal

Michael Poulin wrote:
>
> Sweta,
>
> it involves neither programming nor 'just apps' but architecture and
> training takes several years...
>
> - Michael
>
> ------------------------------------------------------------------------
> *From:* sweta.dave <sweta.dave@...>
> *To:* service-orientated-architecture@yahoogroups.com
> *Sent:* Sat, November 7, 2009 6:16:45 PM
> *Subject:* [service-orientated-architecture] help me
>
>
>
> hi
> i m new to SOA.Can anybody tell me what it is.It is worth to get
> trained in SOA to grab job .
>
> It involves any programming or just apps.
>
> thanks
>
>
>

2009/11/8 Jan Algermissen <algermissen1971@...>
>
>
>
> Steve,
>
> On Nov 8, 2009, at 1:05 PM, Steve Jones wrote:
>
> > This is the bit that surprises me about REST advocates. On the one
> > hand they champion an extremely rigid and limited interface as being
> > the right way to do things and in the same breath claim that rigid
> > interfaces are a bad thing.
>
> I made a mistake in terminology there 'rigid' should have been
> 'specific'.
>
> So, REST advocates prefer the uniform interface over the specific
> because the
> uniform interface has advantages over the specific[1]

A claim without much evidence.  I'd argue that my claim that specific
interfaces with tight definitions have significant advantages over
undocumented dynamic interfaces.  802.11x, HTTP, GSM, etc, etc, etc

Steve


>
> Sorry for the confusion.
>
> Jan
>
> [1]
<http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_\
5
> >
>
> --------------------------------------
> Jan Algermissen
>
> Mail: algermissen@...
> Blog: http://algermissen.blogspot.com/
> Home: http://www.jalgermissen.com
> --------------------------------------
>
>

Steve,

On Nov 8, 2009, at 1:05 PM, Steve Jones wrote:

> This is the bit that surprises me about REST advocates.  On the one
> hand they champion an extremely rigid and limited interface as being
> the right way to do things and in the same breath claim that rigid
> interfaces are a bad thing.

I made a mistake in terminology there 'rigid' should have been
'specific'.

So, REST advocates prefer the uniform interface over the specific
because the
uniform interface has advantages over the specific[1]

Sorry for the confusion.

Jan

[1]
<http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_\
5
  >



--------------------------------------
Jan Algermissen

Mail: algermissen@...
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------