I guess that "> A major problem in adopting RPC style is that, the exchanged XML > documents cannot be validated against an *XML Schema Definition (XSD).*" was > about RPC for object exchange where may be no place for Strings (XML) - > classical OO API. However, if one thinks a bit before coding, RPC can > perfectly wrap any document in XML with XML Schema validation. Another thing > is if instead of thinking you take a Java class, e.g., and automatically > convert it into WSDL - produced RPC has no chances for XML Schema validation > (this is the job for a monkey, not for a SW Engineer).
- Michael ________________________________ From: Steve Jones <[email protected]> To: [email protected] Sent: Wed, December 9, 2009 9:57:32 AM Subject: Re: [service-orientated-architecture] Miko on SOA Governance 2009/12/8 Ashraf Galal <[email protected]>: > "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%20Pant> > 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 <[email protected]> >> >>> >>> 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 <[email protected]> >>>> *To:* [email protected] >>>> *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) >>>> >>>> [email protected] >>>> <mailto:[email protected]> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> ------------------------------------ >> >> Yahoo! Groups Links >> >> >> >> >> > > > > ------------------------------------ > > Yahoo! Groups Links > > > > ------------------------------------ Yahoo! Groups Links
