I don't like UDDI for other (Web-related) reasons, but what I was
taking issue with in this case was the practice of gathering what is
originally decentralized information, and maintaining copies of that
information in some central location (the registry). It doesn't
actually *fix* the problem mentioned (brittle software components),
nor even make it easier to solve, since no new information has been
created by this process. It just makes it more difficult to maintain
the copied information, for all the usual reasons.
So you don't like UDDI. OK. Many others share your taste. Others don't. That's fair. Now, let's look at the 'centralization of decentralized information'.
Where would you store following information: Service classification (Business impact: High; Visibility: External;) Provider: (HR Department); Policy (Every RSS feed must go with Content-Type: application/rss+xml); Lifecycle stage: retirement; Number of consumers: 8; Consuming lines of business: 3; Depends on: some services; Affects: some services, organization units, people; Compliance reports per service; and stuff like that?
Systinet manages this information in the catalog. Some information (for example WSDL document) is often a copy of a document hosted by the real service endpoint. Why do we maintain the copy? Because then the governance authority, sometimes enterprise architect, sometimes release engineer, sometimes operation manager (really depends on company's internal processes), can see what has been approved and what are the changes between the approved copy and the data at runtime - this change detection is done automatically by the catalog. Useful, isn't it? And there are other reasons - possibility to do query over all WSDL documents, possibility to say these are our mandatory business XML schemas, and others.
You might say - OK so let's establish an enterprise-wide policy that every service itself will expose all this information mentioned above. Then you can only syndicate this in some sort of portal. While this sounds good technically, there are many other (and more serious) organization issues that are showstopper in vast majority (or rather 100%) of enterprises I have experience with. And there are of course technical challenges as well.
Right, but that example isn't very applicable to the situation in the
article. If you said that you kept a centralized database of all
comments in your code (separate from your the code itself) then that
would be more analogous... and of course we'd all laugh you off the
list 8-)
Well, my analogy wasn't perfect but your is neither. But it's definitely funny ;-) What you keep outside of code is architecture diagrams, configuration management items such as what distributions use this particular code, what are the other active branches this code is used at, how many non-GA customer modifications were made into this code, what is the readiness of the code wrt some release plan, what are the legal implication of this code. At Systinet, we use centralized (but decentralizable) system called TWiki (to our ultimate satisfaction) for this. There is no way and no reason to put this kind of information directly in the code.
Radovan
Mark.
SPONSORED LINKS
Computer software Computer aided design software Computer job Soa Service-oriented architecture
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture " on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .
--
Radovan Janecek
http://radovanjanecek.net/blog
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
