[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: w3c recomndn and Key Information service specification
radha.arur 11/30/2005 02:58 PM To: <shrikantha.prabhu@wipro.com> cc: pravin.gupta@polaris.co.in Subject: RE: w3c recomndn and Key Information service specification Hi, 1. Common markup for micropayment per fee links is a W3C recommendation. Please see the link -----> http://www.w3.org/TR/1999/WD-Micropayment-Markup-19990825. We have already mentioned that W3C stopped work on that draft though still working on XML signature specification for improvizing web infrastructure services. Also though the example quoted in the site is mentioned only for POS activities, we were thinking whether the same principle could be utilized for all type of charges say portfolio charges . One of the key concern in SOA is to how to charge for the atomic services. This is essential to determine the granularity of the service apart from performance and business definition angle. 2. Key Information System Service is a sub specification of XML Key management Specification. It is the next step in the PKI evolution to simplify the interoperability and implementation issues of PKI. It represents a model where applications using PKI do not have to deploy the infrastructure locally. Rather they send XML requests to PKI components hosted by a trust service provider who would execute those PKI requests. Key Information System Service and Key Registry System Service are two sub- specifications of key management system. Key information system service defines a protocol and its main function includes locating a public key and describing the information that binds the key to the owner of the corresponding private key while key registry system service handles certificate management protocols such as key registration, revocation and recovery. Regards ----- Forwarded by pravin.gupta/Polaris on 11/30/2005 01:42 PM ----- <shrikantha.prabhu@wipro.com> 11/30/2005 01:08 PM To: <pravin.gupta@polaris.co.in> cc: <soa-blueprints@lists.oasis-open.org> Subject: RE: [soa-blueprints] Primer "Common markup for micropayment per fee links" is not W3C recommendation. The work was discontinued on that. Can you guys clarify what recommendatation/implementation are you discussing? And which recommendation is "Key Information System Service recommendation"? Regards Shree -----Original Message----- From: pravin.gupta@polaris.co.in [mailto:pravin.gupta@polaris.co.in] Sent: Tuesday, November 29, 2005 10:53 PM To: soa-blueprints@lists.oasis-open.org Cc: radha.arur@polaris.co.in Subject: Re: [soa-blueprints] Primer radha.arur 30/11/2005 10:41 To: <soa-blueprints@lists.oasis-open.org> cc: Subject: Re: [soa-blueprints] Primer Ken, Thanks for the comments. With reference to your question on reference of W3C standard i was referring to w3c working draft on "per fee links". W3C had come up with a recommendation and there were few implementations based on those recommendation. Though there is no work proceeding on those recommendation, w3c continue to improvize on Xml security notation to improvize the infrastructure for the atomic services. Also, the new - Key Information System Service recommendation which leverage the PKI can also be the reference for the working group to enable thin client encryption. Regards Ken Laskey <klaskey@mitre.org> 25/11/2005 02:32 To: radha.arur@polaris.co.in cc: <marchadr@wellsfargo.com>, <soa-blueprints@lists.oasis-open.org> Subject: Re: [soa-blueprints] Primer some comments inline. On Nov 24, 2005, at 7:39 AM, radha.arur@polaris.co.in wrote: Ken, While i agree a blueprint has to be simple and start with a context in mind, majority of the time SOA implementation issue starts in the beginning when the service defn itself is in a flux even in a single context. e.g when a loan / credit appln says they are different or when overlapping services exist. This issues will become more when the blueprint has to be followed in scenarios where overlapping services offered in a multi vendor scenario and where exactly an SOA appln is warranted. SOA provides a way to connect capabilities; the decision on what capabilities to connect is still a domain-specific decision. Currently, there is probably a human in the loop but hopefully we will eventually create robust decision capabilities. SOA does not make domain-specific decisions and it is wishful thinking to say it will make intelligent decisions when humans haven't figured out what they would do. As for an SOA blueprint, it can indicate the pieces that will be needed no matter what the domain decision. For example, you probably want to monitor what services are being used and how they perform. What level of security/access control do you want to see? What level of assurance do you want that messages go through? In my opinion a blue print for a long running process and hence their process defn should have the following in mind. a. Should not stop the service implementation in stage 1 itself for want of accurate service defn. The adaptive blueprint defn shared with us by ebsoa group for the adaptive, basic and dynamic service pattern for collaborative process may be adopted even in a single appln context. This would seem to be a basic requirement for a blueprint. b. The long running process by Ken example since it needs to be able/capable of utilizing an atomic service, should in my opinion be capable of sourcing plug in services. While a manual entry as stated by Ebsoa comitte is o.k in a non mission critical appln , it may not be desirable in a mission critical situation. Would a BPEL let us do that? In following the previous item, a blueprint should allow domain-specific service to be "plugged in" but we should consider the generic attributes of the long-running transaction. c. The blueprint should also be able to relate pattern to an architecture. Ex - one should be able to gauge from the blueprint what type of basic service patterns could be used. I think we need to decide the relationship between a blueprint and a (reference) architecture. d. I would also like to know the opinion on interoperability of w3c standard for microcommerce market viz a viz SOA basic service defn when we like to apply it for portfolio charges. Which W3C standard are you referring to? There was work several years ago on micropayments but that never resulted in a Recommendation. regards Ken Laskey <klaskey@mitre.o To: <marchadr@wellsfargo.com>, <jinu.joseph@polaris.co.in>, rg> <soa-blueprints@lists.oasis-open.org> cc: (bcc: radha.arur/Polaris) 23/11/2005 21:09 Subject: RE: [soa-blueprints] Primer OK, now we're getting to some meaty issues :-) It would seem that a useful pattern would be a long-running business process, where the "business" could as likely be technical as commercial. What are the requirements of such a process? What assumptions do we make about the process? What are the notional pieces of a solution? How do these pieces notionally work together? Where are there alternatives? Finally, what combination of completed standards, specifications within standards committees, and private specifications will likely enable such a blueprint? Note, part of the output of this thought process could be feedback to existing committees on what is needed from their specs or how the process needs to be curtailed to fit the current and evolving standards. Ken At 10:24 AM 11/23/2005, marchadr@wellsfargo.com wrote: Jinu these are good points. Something I would say to this would be that in most implementations of SOA there are basic structures that could be followed with the variation being the actual business logic. Even within a certain space there are multiple blueprint needs. For instance, - Fulfilling a loan may be a long running process that might take into account a workflow with certain security requirements etc... - While making a wires transfer would have to be highly available and have routing based on fraud and security rules without the need of long running process To apply them to some of the cases within the soalogic approach you could see the following: 1. Based on the process of developing a product within soalogic they need a managed long running process. This pattern without the specific business logic could be applied to the loan case. Or could even be applied to strategic budget planning, etc... 2. The retail store is using a pos process that needs to be secure and have fraud detection for purchases made by the customer this could be applied without the specific business logic to a wire transfer case. The actual blueprints could be extracted for 1 that state: - WS-BPEL - manage the long running process - Transport types that could apply (HTTP/HTTPS/MQ) - WS-Security - for managing who is able to update from a client auth perspective - WS-Coordination - to coordinate with different SORs - WS-Notification - to alert either an operation or customer service agent of an issue within the process through an intermediary service - WS-Profile - for indentify the service - WS-CAF - to provide context around who the requestor is - Fault Management - how and what type of responses would happen, sending an WSN event? - XACML - for determining the rights of the user invoking the service - etc... So what you end up doing is creating a stack of patterns that could be applied to a problem area that involves long running operations or short fast operations, etc... Of course the specific technology may not be decided upon within the blueprint but the concepts within WS-BPEL will be abstracted with an example implementation of how WS-BPEL fulfills the specific request. Essentially think of the types of services you have ever created and think about a lot of the common problems you had to solve along the way to get specific business logic to be invoked within a service context. There are a lot of problems that are common across implementations such as security, event management, auditing, even in some cases accounting to chargeback for a service invocation to a specific customer or internal client. Some of these could be in a ESB or some could reside with the service and it may be worthwhile to come up with a sample deployment for each blueprint that may determine the type of system needs associated with the blueprint. I'll try and come up with an example at the end of the week or next week so you don't think I am crazy :) - Dan -----Original Message----- From: jinu.joseph@polaris.co.in [mailto:jinu.joseph@polaris.co.in] Sent: Tuesday, November 22, 2005 7:58 PM To: soa-blueprints@lists.oasis-open.org Subject: RE: [soa-blueprints] Primer Hi Folks I am just thinking aloud here. I feel that while a blueprint does give a kind of basic map while moving into uncharted territory, it still has the following limitations - Blueprints as discussed are limited to a category of contexts. Going by the house analogy the blueprint i need for the house will be dependent on who I am and where I want to build the house. If I am the President of the United States, then I cannot build the house using the same blueprint that you and me would use, Similarly if I would use different blueprints to build my house in the Sahara Dessert and my house in Antarctica. What I am trying to say is that the Blueprint might applicable for a type of system and may not be useable for all software systems wanting to go the SOA way. The SOA blueprint for the Financial Services Systems used by Banks would be different from that used by Corporates for their Inventory Management System. - Trying to make a generalized blueprint will lead to such a high level of abstraction that the blueprint itself might not be of much use. Going back to the house analogy trying to make a generalized blueprint might lead to the blueprint only containing guidelines like, there should be a foundation, there should be a ceiling, there should be windows etc... - What I feel is that we should have SOA blueprints based on software segments such BFSI segment, ERP segment, Services like Utilities etc. What do you say ?? Regards Jinu Joseph Polaris Software Lab Ltd e-mail: jinu.joseph@polaris.co.in <marchadr@wellsf argo.com> To: <klaskey@mitre.org> cc: <soa-blueprints@lists.oasis-open.org>, (bcc: jinu.joseph/Polaris) 23-11-05 03:53 Subject: RE: [soa-blueprints] Primer AM See comments below. Good feedback Ken. -----Original Message----- From: Ken Laskey [mailto:klaskey@mitre.org] Sent: Tuesday, November 22, 2005 12:07 PM To: Marchant, Dan R. Cc: soa-blueprints@lists.oasis-open.org Subject: Re: [soa-blueprints] Primer At 09:50 AM 11/22/2005, marchadr@wellsfargo.com wrote: Ken these are questions that I am sure with be concretely established by this tc. Here is my take (keep in mind I am on a blackberry so it might be more terse than normal). 1. A blueprint in my mind is to establish a structure to an other wise disorganized approach to developing software. I have typically called blueprints a reference architecture (not to be confused w/reference model). 2. Think of the scenario of buying building blueprints from a house designer and than having though blueprints tweaked by a local architect of the house. Maybe for your requirements you need the kitchen closer to the family room or a water closet turned into a walk in closet. Whatever the changes the basic structure is defined for what you need to accomplish building a house with N number of rooms that each have a function. You might find this analogy interesting: Go back to our house analogy. The RM captures concepts related to what makes up a house, e.g. room, window, door. It might include the concepts of food preparation area and personal hygiene area and the relationship that there should be physical separation between the two. Note that this provides a very North American/western Europe reference and not necessarily one that covers a tent. So a given RM already provides a perspective. Given RM concepts, various RAs show how these concepts can be arranged in a useful pattern. So RA examples would be (sorry for the American terms) a colonial, a split-level, a rambler, etc. You can play with the pattern but one can say that any given pattern serves a particular set of purposes (e.g. a rambler is on one level for those who want/need to avoid stairs). An architecture is then a specific plan to build a house or set of houses. There can still be some variations but you don't do things like moving fireplaces or structural walls, else you have a new architecture. [Marchant, Dan R.] Sounds a lot like the movie "Kitchen Stories" about the period of time where sweden was conducting studies on the usability of a kitchen to identify patterns of usage. In some ways the development of a blueprint is similar in nature to the kitchen studies in the 50s. Is a rambler a ranch style house? I agree with the structural statement creating a bit of constraints that take care of the reduntant nature of developing an SOA. Everyone in the US probably has a water closet (bathroom) in the master bedroom a pattern that is identified based on the experience of the architects in finding the needs of the consumer of the house. Likewise the blueprints can evolve by building on the reference model. 3. To establish direction or rudder the ship. You need to establish the pie in the sky and a blueprint can help get a handle on that pie. If you have a ship without a rudder, you are likely beyond being saved by a blueprint :-) 4. There is a type of tracability that can be accomplished through following a blueprint. Also it may be important to use a third-party blueprint to establish a motive for changing the way a business does things, not sure if this applicable for everyone but there is definely value in having something to refer too. Good points. Now can someone craft those into a paragraph or two that any of us can present to a client and they would feel they know something they didn't know before? [Marchant, Dan R.] Wiki ? My take is this on the blueprint roadmap so to speak. 1. Establish a couple different scenarios where services would help and how the service would be structured within that context and including supporting services. 2. Take the scenarios and generalize them into patterns with some technology choices as and example of implementing pattern. 3. Establish an overview of how all the supporting services could be structure to support the various patterns. It would essentially turn into a type of framework, a service could follow and establish the need for supporting services in a formal way. Step 2 after you define a blueprint is to lay out how you would create one. Your roadmap looks like a good initial approach, both for motivating a blueprint and showing how one blueprint can/should/might support more than one scenario. I could see it on the same lines of developing anything spring or a portal. You have a set of facilities that are applicable for certain scenarios that than could be implemented of configured appropriately. The great unknown being what business logic is performed but most of it could be generalized into some type of pattern. For example, transaction based, inquiry based, aggregation, or even everyone's favorite semantic service. Thoughts from the group? Dan -----Original Message----- From: Ken Laskey <klaskey@mitre.org> To: Marchant, Dan R. <marchadr@imc.wellsfargo.com> CC: soa-blueprints@lists.oasis-open.org <soa-blueprints@lists.oasis-open.org> Sent: Mon Nov 21 22:42:48 2005 Subject: Re: [soa-blueprints] Primer I have not been following the email carefully enough, so forgive me if this has already been established but 1. Exactly what is a blueprint? 2. What purpose does it serve? 3. Why should I think one will be generally applicable? 4. Why do I care? Do we expect that a blueprint will be a sort of turnkey formula? How do we determine the limits of applicability for a given blueprint? Are there underlying assumptions that all blueprints have in common, or is each blueprint fundamentally different (a very possible construction), or are there fundamental groupings with multiple non-redundant examples in each group? I think agreeing on a clear strawman definition of blueprint is essential. It can be modified as we learn more but we need a clear starting point. Ken On Nov 21, 2005, at 9:12 PM, <marchadr@wellsfargo.com> <marchadr@wellsfargo.com> wrote: One question to pose to the group is maybe the case study actually becomes a type of primer for the blueprints once the blueprints are defined. Thoughts? Dan --- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 -- --------------------------------------------------------------------------------- / Ken Laskey \ | MITRE Corporation, M/S H305 phone: 703-983-7934 | | 7515 Colshire Drive fax: 703-983-1379 | \ McLean VA 22102-7508 / ---------------------------------------------------------------------------------- This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit Us at http://www.polaris.co.in -- --------------------------------------------------------------------------------- / Ken Laskey \ | MITRE Corporation, M/S H305 phone: 703-983-7934 | | 7515 Colshire Drive fax: 703-983-1379 | \ McLean VA 22102-7508 / ---------------------------------------------------------------------------------- This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit Us at http://www.polaris.co.in --- Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit Us at http://www.polaris.co.in Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit Us at http://www.polaris.co.in
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]