The Convergence of Business Process Management and Service Oriented Architecture
http://www.acm.org/ubiquity/views/v8i24_bmpsoa.html?searchterm=soa+group Enjoy it All the best Ashraf Galal ----- Original Message ----- From: Jerry Zhu To: [email protected] Sent: Saturday, April 12, 2008 2:24 PM Subject: Re: [service-orientated-architecture] Re: XSD governance I think we need to identify the right level where the problem orginates. If the problem is the gene composition (DB Schema), plastic surgery (XSD) wont work. The idea of mutiple data structrure for same data type is not a good one. It plays Jigsaw, rather than tangram, puzzle. The idea of data normalization is to store base, not derived, data. For example, if a DB needs to capture employee's info about all spouses (live or dead). HOw to do it? Stop reading my email now to think about solution. Now we have an employee table with attributes of spouseName1 and spouseName2. What about three or more spouses. That DB schema will break. Here is how I do it with three tables. Employee, Dependent and Person_type. Each emloyee has multiple dependents each of which belongs to a type. This way it opens to unlimited # of spouses and even open to new person types such as domestic partner. Adding spouses and new person types wont break anything. This distinction of base and derived data applies to Service level also in creating XSD structures. The question is whether the standard XSDs are base or derived data. Jerry --- Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > I'm talking about defining the common data > structures (simpleTypes and > complexTypes) that will be used within messages. I > believe that's what > Leonid was asking about. Table and record types, as > well as object types, > are distinct from message types. You can think of > message types as a > standard serialization format, but perhaps that's > too restrictive, because > XML structures can be processed in their serialized > form. > > In my experience, defining common documents > (elements) is much harder > accomplish -- mostly because applications often > require specialized > information. Documents are composed of types. Where > possible, those types > should taken from the corporate standard type > library/catalog/repository. > > The common best practice when using SOAP currently > is to use "wrapped" > document/literal. In this case, the "documents" > exchanged in an operation > are specific to the operation. If your operation is > called submitOrder, then > by convention the input document is called > "submitOrder" and the output > document is called "submitOrderResponse". And these > elements belong to a > namespace defined specifically for this service. It > would be inappropriate > to attempt to share these documents. But, the input > document is very likely > going to contain an Order -- that Order structure >should be based on a corporate standard XSD datatype. > > Anne > > On Fri, Apr 11, 2008 at 6:05 PM, Jerry Zhu > <[EMAIL PROTECTED]> wrote: > > > It appears to me that Ann and Leonid talked two > > different things. > > > > Data Ann talked about is at or below Object level. > A data record, even table structure, can be > represented > > in XML defined by a XSD. It maybe useful but not > > accross the board. At least I have not used it > yet. DB > > can be designed none extensible or extensible. One > can > > hardcoded cutomer types or have type extensible or > > open ended. It is the technique of DB design not > about > > XML. Relational data is at object/component level > and should not be accessed by Services if levels of > > abstraction is applied. > > > > XSDs Leonid talked are about service interface > > descriptions...data at service level, not object > > level. Data at this level is really document hence > not relational but hierarchical. This hierarchical > > structure can be standardized at certain levels > made > > reusable. Composing documents are simply drag and > drop nodes at different levels plus adding unique > nodes. I think there are many benefits doing this. > > > > Jerry > > > > > > --- Anne Thomas Manes <[EMAIL PROTECTED] > <atmanes%40gmail.com>> wrote: > > > > > Leonid, > > > > > > You've raised a new issue that has the potential > to become a perma-thread on this list! > > > > > > I disagree with both Michael and Rob. > > > > > > From my perspective, the fundamental shared unit > in SOA is a data > > > type. Data is the lifeblood of a SOA initiative. > But data can also be > > > its downfall without governance. I strongly > > > encourage organizations to > > > define a base vocabulary of types -- for > entities such as customer, > > > product, order, item, etc. And unlike Rob, I > think these types should be defined using XSD. > > > > > > Vocabulary management has not yet become a > prevalent practice, which I > > > find very odd, because it has such far-reaching > > > benefits. The > > > discipline recognizes that an organization can't > > > survive with only one > > > data structure for "customer" -- so it focuses > on defining a set of > > > structures that support the various requirements > > > across business > > > domains, and provides semantic mappings across > those structures. This > > > effort should also map internal types to > industry standard types (e.g., ACORD). > > > > > > Vocabulary management can be accomplished using > pen and paper or > > > simple documents, but it's much easier if you > use a repository to > > > manage the lifecycle and interdependencies of > your XSD artifacts > > > (types, attributes, and elements). Product > > > categories include XML/XSD > > > repositories (which often come with XSD tools), > SOA repositories, > > > software asset management systems, and > vocabulary management systems. > > > > > > SOA repositories that are particularly good at > > > capturing and managing > > > XSD artifacts are HP Systinet and IBM WSRR. > High-end vocabulary > > > management products include Progress DataXtend > SI and Liaison Contivo VMS. > > > > > > Anne > > > > > > On Thu, Apr 10, 2008 at 4:00 PM, Rob Eamon > > > <[EMAIL PROTECTED] <reamon%40cableone.net>> > wrote: > > > > > > > > My input would be to focus on *document* > > > definition and management > > > > from which XSDs may/may not be created (or any > > > other definition representation) depending on > usage need. Limiting the scope to "XSD > governance" would be, well, limiting. > Documents > > > to be managed won't always need to be defined by > > XSDs, probably need to be defined in > > > > other representations as well, and won't only > be used solely by services. > > > > > > > > The "document type management team" would >manage the document lifecycle, including creating new, use/modification of existing, and > > > > retiring. The team can get as sophisticated as >needed in terms of defining policies around the areas you mentioned. Knowing the list of > document types "in play" would be a good start. > > > > > > > > -Rob > > > > > > > > --- In > > > > [email protected]<service-orientated-architecture%40yahoogroups.com> > > , > > > "lfelikson" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > From perspective of service design and > service > interface definition practices, it is a well-known > === message truncated ===
