> So I guess I am saying that if you go into SOA in order to get reuse do
> not expect direct help in determining what to reuse from any tools such
> as UDDI repositories/registries/ESB's or indeed anything that I have
> seen (and I have seen quite a lot). Perhaps the assembled masses have
> some suggestions, but I think it is likely that it is a methodological
> approach supported by the right tools and languages that is required to
> help us get reuse in any sensible fashion.
My years of software development and design have taught me that its very hard,
if not impossible to create the perfect architecture the first time. So, you
need to have software platforms and design architectures, at your disposal
(through your knowledge base or tools at hand) that allow you to manage the
versioning of your system effectively. You need to be able to reuse your
services in one form or another. Some of the most difficult to solve problems
come about from the attempt to make everything fit into one container.
Sometimes that is important, other times its detrimental.
You have to be prepared to tackle reuse and versioning in effective and
intelligent ways. Some tools provide such features inherently.
The XML/document model provides the opportunity to add document
elements/attributes and to copy document trees with variations so that you can
adjust the available structure of the document for applications that need
different features. If this creates a large replication of content, you can
either live with it (and risk dependency on the old content expanding without
your knowledge), or you can create a new service that provides the new document
content. If your lucky, you might just rev the document and force the clients
to change.
In platforms, such as Java, which provide mobile code capabilities, you can
utilize the mobile code features to provide a client side conversion of the
servers API into the interface that the client understands. If the client is
not Java based, then you can utilize server side invocation layer and endpoint
conversion to make sure the client only sees the content that it needs.
One of the key mechanisms for enabling just-in-time content is authentication
and explicit version negociation in your API/transport.
Gregg Wonderly
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.
