I assume people reading this article are already familiar with SOA & SOAP. SOA principles are not new for someone who has explored it from the days of RMI/CORBA or Microsoft COM/DOM. One such technology that is still popular even today & significantly unique & worth mentioning here is REST ( termed as Representation State Transfer). REST is a style of architecture where a collection of distributed hypermedia resources are addressed & accessed without any additional burden of a messaging layer such as SOAP & without the need to manage session tracking via HTTP cookies, making possible to build robust applications simpler, faster & easier. REST lays emphasis on how resources are defined & addressed. See video here ..
We all know DFS stands for Documentum Foundation Services and there are 13 foundation/standard/platform services and many additional Extended services that are technology platform specific such as DFS content services for SAP. Let us first recap a bit on the importance of SOA. We have known of business logic tier and database tier in traditional JEE applications. The business logic tier consists of functions which are reusable validating business logic & processing it. If you extend these systems furhter then you’are talking about integrating & interacting many such systems with each other. As we all know, such interactions are not possible because each application system has its own language, datatypes etc. So they dont understand each other even if they are able to talk. Then, here comes a WSDL and believe me the whole SOA revolves round this. It is the core contractual document(an xml file) that defines the services that can be called and what is expected as arguments before you make a call. More importantly such interactions can be packaged into a standard service and of course the essence of interaction is to embody the business logic into that service. But the trick here is you can change business logic by keeping the contract/wsdl constant. But its important to remember that a contract is once and for ever unless you want to rebuild the whole thing again. So be cautions to build a fairly robust WSDL contract.
Briefly, different applications can enable integration by exposing their business functionality as services and it is not possible to invoke a service without a prior agreement in the form of a WSDL file.
Typically a DFS WSDL will have the following elements defined.
1) Types: defines data types
2) Message: “” typed definition
3) Operation: “” description of operation
4) Binding: “” protocol & dataformat
5) PortType: “” abstract set of operations
6) Port: “” Single endpoint wit binding + network address
7) Service: “” Group of related endpoints
I believe you will be able to understand that all the elements come with <> and you can add your imagination to my brief description. Discussing the full WSDL will be too elemental.
The UDDI Registry: All services must be registered with a UDDI Registry for easy discovery by other services trying to find them(unlike REST). So instead of looking into the whole web they can look at just one place. UDDI stands for Universal Description & Discovery Interface. Every time a service is registered, the UDDI-Registry retains a copy of the WSDL for its own reference. A registration involves the U-Registry knowing its descriptions and all the operations defined in it.
Insert diagram here ..
Coming back to services, the standard services are categorized into 5 categories.
- Core: has
- Object Service
- Version Control
- Query Store
- Access Control
- Virtual Document
- Search Service
- Task Management
- ci(content intelligence)
- Analytics service