Java Reference
In-Depth Information
vague, or hype-laden, which can make it difficult to know that everyone is actually talking
about the same thing. Using a glossary for terms, such as service, contract, governance, and
so forth, can aid meaningful communication.
Documentation
Here you can link to JavaDoc, project documentation, vendor documentation, requirements,
use case documents, modeling analysis documents, and other such items.
If you have IT or business roadmaps or other enterprise architecture documents that might
play a role in building out your SOA, you can link to them here as well.
Artifacts
If your infrastructure allows it, you might consider having a view into the runtime artifacts
within your SOA. These might include centralized schemas, business process modeling doc-
uments as derived from a modeling tool, visual representations of BPEL orchestrations, and
other items. Offer appropriate users insight into monitoring tools so that they have the inform-
ation necessary to make good decisions about new service candidates, SLAs, new composi-
tions, or infrastructure changes.
News
You might consider establishing a feed that aggregates various SOA-related websites into your
reference architecture portal. This helps to keep everyone abreast of industry trends and give
your team the best chance to keep one another informed.
Conclusion
While some of the items indicated here may seem excessive, remember that the purpose of
the reference architecture is manifold: it serves to instruct newcomers on the way that you
want web services done in your organization; it helps experienced developers find and use
web services that your organization has written or endorsed; and it helps the governance board
or Center of Excellence make decisions regarding service candidates and future architectural
directions.
