Posts tagged mds
It has been almost a year since my last post about the metadata services. I talked about how-to set up a File-based MDS and DB-based MDS. This post talks about the usage of the files, placed in the MDS, in the different components available in a SOA composite. If the MDS is a new thing for you then I advise to read my previous about this subject first.
You can spot the presence of a file that is a reference to the MDS if it uses the oramds: URI annotation. Files are no longer referenced to a hardcoded or relative file path.
To start using you’re MDS that you have set up we will create a new SOA application. Let call the application WorkflowSOAapp and create a SOA project and call it WebformService.
In a recent post I wrote how wonderful the ADF support for user level customizations or personalizations is, and then I went on to explain how the user can be enabled to remove her own personalizations (http://technology.amis.nl/2012/09/27/adf-undo-the-users-page-personalizations-query-and-manipulate-mds/). This article a sequel to that story. It will introduce the capability for one user to clone the personalizations from another user. This means at the background that the document that contains the customizations for a page for the ‘source user’ is read and a new document with the exact same contents is written for the ‘target user’ who will then have personalizations that are at that time exactly the same as those of the source user. There is no link between the two documents – they are both on their own. Any pre-existing personalizations for the target user are lost in this process.
Note: I do not talk about the privileges that you want to define in order to not have anyone copying from just anyone else. Also note that I discuss cloning the personalizations for a single page only. Copying all personalizations from one user to another however is a very simple extension of what More >
One of the quite powerful features of ADF is the built in support user customizations also known as personalizations. A user can apply changes to an ADF web page – rearranging some of the layout, configuring advanced components such as tables and generally fine tuning the look and feel to the user’s individual needs. If the application is so configured, these changes are retained during the session (for each next visit to the page) or even across sessions (for each next visit to the page, also after an intermediate log out, in an entirely new session).
The framework provides declarative support for registering and reapplying the personalizations made by the user. These are held in the MDS Repository, in an XML file that contains the deltas that the user is (indirectly) requesting to have applied on top of the base sources of the application.
The framework does not have built in out of the box support for resetting the page – returning it to its factory level, the state in which the developers created it. The customization document needs to be removed from the MDS repository when the user wants to undo the personalizations made. To accomplish this, we need to write a little code More >
Before I talk about the advantages en methods of using the MDS, I want to introduce myself, because this is my first public post on the AMIS technology blog. My name is Robert van Mölken and I’m 26 years old. I’m now actively working, as a SOA Consultant / Developer, for nearly 5 years. My main toolstack is SOA Suite (3,5 years 10gR3 and 1,5 years 11gR1), but also have experience with opensource BPEL / ESB alternatives from Apache.
In many big SOA application all the composites use the same canonical1 data model (message definitions) for their service contracts. Many entities and elements (complex- and simple types) are reused. Therefor it is not a good choice to use a local copy for the service contracts (WSDLs) and message definition files (XSDs) in each SOA composite project.
If you do so and a mayor (common) part of the message definitions changes then you need to update all the SOA composite projects, where these files are used, with the new version of the files. Oracle created the MDS to solve this issue. MDS stands for MetaData Services. The MDS holds all kind of xml-based files, like WSDLs, XSDs, Domain Values Maps but can also hold fault policies and event definitions More >
It will be my last presentation at Oracle Open World 2009 – how to turn any ADF application into a SaaS application – an application suitable for deployment ‘on the cloud – available to users from different organizations’. One of my statements is that most if not all applications benefit from applying those same SaaS concepts. It makes applications running within the walls of an enterprise more agile, more manageable, better suited to the specific needs of individual users and user groups and easier to integrate in the IT landscape of the enterprise, both at the services level (SOA, ESB) and at the user interface level (Portlet). The presentation will discuss a number of facilities and characteristics that are desirable in SaaS applications as well as other Web Applications.
If you are interested in attending and watching the live demos, please come to the session: S307483 Castle in the Clouds: SaaS-Enabling Oracle ADF Faces Applications (Wednesday 14th October, Time: 11:45 – 12:45, Marriott Hotel, Salon 3).
One of the rather cool pieces of functionality that did not make it into the JDeveloper 11g Boxer release of early October 2008 is the Meta Data Service or MDS and especially its capability to store and reapply user created personalizations of the User Interface across sessions. Some simple examples of what this means: ADF 11g Rich Client Components allow users to manipulate the state of components – such as the position of the separator in the PanelSplitter, the ordering and width of Table Columns, the initially visible tab or accordion child etc.. Through MDS, these changes are captured and stored for th duration of the session (if so desired), which means that when the user returns to a page thus ‘personalized’, the component will not assume their default state as specified in the JSF page at design time by the developer, but rather the state that user specified. Eventually MDS will persist these component personalizations across sessions – but not right now. That means that at the present when a user starts a new session, all components are presented in their default state.
In this article I will describe two things: Change Persistency for all attributes – not just the More >