Yup, I'm with that, it still means its possible to validate at the client side no matter what.
Steve 2009/12/10 Dennis Djenfer <[email protected]> > > > Steve and Ashraf, > > I hope I'm able to shed a little light on the possibility to validate > RPC/Literal-style messages. > > It is possible for a SOAP-engine with access to the WSDL-file and > XML-schema files to validate an RPC/Literal style SOAP-message. However, > it's not possible for an intermediary that only has access to the XML-schema > files to validate an RPC/Literal style SOAP-message. The reason is that with > RPC/Literal style there is not a complete XML-schema for the whole message, > instead there is a schema for each part of the message. A validator must > have access to the WSDL-file, and with knowledge about the SOAP-conventions > it is possible to validate different parts of the SOAP-message against each > corresponding XML-schema. > > // Dennis Djenfer > > > > > Steve Jones wrote: > > 2009/12/10 Ashraf Galal <[email protected]> <[email protected]>: > > > Steve Jones wrote: > > > 2009/12/8 Ashraf Galal <[email protected]> <[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. > > > > Please note here is that the schema defines only the complex type > parameters. > > *It does not give any information useful to validate either the other > simple parameters, or the rest of the SOAP message. * > > Therefore, a major problem in adopting RPC style is that, the exchanged > XML documents cannot be validated against an *XML Schema Definition (XSD).* > > > Seriously, I'm not sure that you know what you are saying. Please > tell me the specific thing that prevents you doing this validation. > Despite the obvious piece that if you generate your code (or proxy) > directly from the WSDL/XSD then it will have this in, the document and > its schemas are published in the WSDL and therefore are available for > validation. > > > > Although, it is useful in cases we have to expose the legacy systems > without refactoring it or we want to send message over SMTP. > > The "encoded" value for the *use* attribute is prohibited by WS-I. > > Validating a SOAP encoded message against a WSDL description is quite a > hard work, and since the validation is a fundamental step toward > interoperability, only the use "literal" is allowed by WS-I. > > One of the major weaknesses of the RPC approach is the tight coupling > that it imposes on architectures. > > A change in a service method signature has an immediate impact > throughout the system, forcing the refactoring up to the client layer. > > > These set of statements make zero sense. Either you can't do > validation or it has an immediate impact, it can't be one or the > other. > > > > > 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. > > It is not just that, it is more than that. > > > > > 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. */_ > > > > Want a bet? > > > > Optimizing a process is not an easy task,and it involve human and > applications and takes time. > Unfortunately, all of these methodology uses the big-bang approach while SOA > takes a different path. > BPM has contributed significantly to the liberation of business from > technology, even if it done by IT stuff. > Coupled with SOA,BPM is even more powerful. > Sorry, I don't like betting :-) > > > BPM is a technology piece, it doesn't liberate business from > technology it just means that if used properly the technology should > be easier to maintain and modify. > > Or are you saying that end-users are now modelling processes and then > having them executed directly without IT ever being involved and > without a traditional SDLC being required.... > > > > 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> > > <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> > > <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. > > > > >From my previous email: > > > > [snip] > > Ashraf, there is very little point debating or discussing if you don't > address any of the points. I know what BPMN is, I spent yesterday > with the "exciting" challenge of a programme area which has 3 > different process modelling tools which have no lossless exchange > between them. The issue is not whether I know about these > technologies but about the difference from viewing this as a business > problem which can be aided by technology against technologies being > the answer, we just have to find the business problem. > > Business Processes are just ONE way of modelling PARTS of a business > and they are a long way from the only way or indeed the best way in a > complex world. > > Steve > > > > > All the best > > Ashraf Galal > > > Steve > > > > All the best > > Ashraf Galal > > Steve Jones wrote: > > > > 2009/12/8 Ashraf Galal <[email protected]> <[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]> <[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> > <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]> > <[email protected]> > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > > > > ------------------------------------ > > Yahoo! Groups Links > > > > >
