One of my colleagues, Robert Ly, has posted a BOF tutorial to the EMC Community Network that consolidates a lot of information pushed out separately by myself and Don Robertson, providing a nice overview of BOF development with a good level of contextual information.
Here is the link:-
https://community.emc.com/docs/DOC-4360
Happy Composing!
Using DAB the mode de jour was to develop against a Docbase; live, connected, whatever you want to call it. You nominated a "System of Record" Docbase. You then went about the business of defining all the artifacts; types, lifecycles, workflows, relations and so on and so forth, that collectively made up your Docapp (a DOCbase APPlication).
Your application(s) code would never execute against these particular artifacts, in this particular Docbase; because they really were just the definitions of resources that your application requires to be present in a production Docbase in order to run correctly. Meanwhile, the rest of your application artifacts; java classes, servlets & jsps, XML, etc, were all managed out of a source control system.
To prepare a content-rich application for distribution. Release engineering (releng) would checkout all the application artifacts, build and package them as an installer or as a war or an ear. They would then also export the associated Docapp as a Docapp Archive and place with the application package. These resources were then placed on a download site where customers could find them.
To install the application the customer would use the installer or deploy the war or ear. He would then use DAI to install the docapp archive into one or more production Docbases.
So, that is how it was. The System of Record for your source artifacts was the Docbase itself. But what was so wrong with that I hear some of your ask? Well a few things as it happens:-
1. Having different Systems of Record is just plain wrong, and what made us so special anyway?
2. Versioning semantics for Docbase artifacts is not always the same as they are for source control, complicating development, histories, labelling and snapshoting
3. Releng needed to have and to know Docbases and to construct Docbases processes (not all of which were that automatable) which was hugely burdensome for them
With reference to the versioning semantics. It is important for us all to recognize that the Docbase is just plain bad at development versioning. For example, types in a Docbase cannot be versioned but code certainly depends on particular versions of types. Now if we could have reliably versioned artifacts then we can support explicit versioned dependencies, even when the target environment does not support it. Explicit versioned dependencies allow us to bind code to specific versions of Docbase resources and have those dependencies validated. The upsides of reliable versioning are hopefully evident.
Recognizing that content management would soon standardize through efforts like CMIS. Recognizing that this would foster and entire industry of organizations building content-rich applications we knew we would have to address these shortcomings and move more mainstream.
So we built Composer and a system of linked XML-based artifacts and an install process that can transform these XML-based artifacts into Docbase objects, preserving the links by converting them to Docbase links; i.e. OIDs.
No longer is there a need for a "System of Record" Docbase. Docbase artifacts can now be developed in the same eclipse IDE right alongside all your other application artifacts. They can also be managed out of the same source control system, giving us reliable version semantics and greatly simplifying the releng process.
OK so we have ironed out that little wrinkle. Docbase artifacts are now analogous to other source artifacts and therefore we are all now followers of the same development model. In this respect we’ve become a bit more standard and hopefully removed a big barrier to entry for release engineering departments. We believe this will help promote EMC|Documentum as the platform for developing content-rich applications.
So what’s next?
In a word "OSGi".
A phenomenon is sweeping the java community in the form of OSGi, a dynamic module system for Java. Most application servers are OSGi-based already. And this phenomenon will undoubtedly impact the ECM community too.
OSGi is mature. It is over 10 years old and has grown out of embedded systems world. So this is not new technology by any stretch. It may just be new to some of us. It is also standards-based.
OSGi promotes a world of modules (bundles in their parlance) that can be dynamically inserted (or removed) into any live, running system with no interruptions in the services it provides. Each bundle has versioned dependencies that the system will honour and enforce these. And a system can support multiple versions of a module at any one time.
For all these reasons (and many others) I believe that OSGi is the perfect fundamental building block for next generation ECM solutions and solution frameworks.
It is also very important to recognize that in this future world of solutions and solution frameworks we may well also see direct, application hosted, manipulation of our XML systems of record. As well as continuing to support the more traditional offline development model, both will co-exist quite happily side-by-side. This direct manipulation will be supported by a family of web-based tooling built on the central core of the Composer tooling platform.
But this is still a little way in the future. Because OSGi will effect how applications are delivered the most noticeable change you will see in the short-term will be to our friend the dar (Documentum Archive) which I believe is already set to become an OSGi bundle. This will prepare the way for it to be just like every other piece of the solution. Developed the same way, delivered the same way. Depended upon, dependent upon others. Really binding into the application as the vital constituent part that it really is.
So what conclusions should you draw from this?
Well if you are considering developing a content rich application (or larger) on Documentum then you need to be following Composer’s lead and adopting model-driven development. Making XML models a central tenet of your development practices is the right thing to do. Leverage Composer, the tooling platform, and in particular its EMF-based modelling and your not going to go too far wrong.
Also getting more involved in Composer, the tooling platform, by extending it for your purposes by adding your own Docbase artifacts would be an excellent way to introduce yourself to the wonderful world of OSGi.
Happy Composing
Jani has done a great job putting together a series of videos as a step-by-step guide to using Documentum Composer. They have now been uploaded to our new community.
Happy Composing!
Today’s a first for EMC.
For the first time ever you can download a completely free version of the EMC Documentum for development, the EMC Documentum Developer Edition. The one-click install includes the Content Server, DFS, Composer, DA and Webtop. All the tools you need to develop enterprise content-centric applications.
To compliment this we’ve also launched a new developer-oriented community.
Enjoy and as always happy composing!
My colleague David Louie, the Composer product manager, posted a nice demo on the EDN site demonstrating how to build and use a smart container.
One way toconsider a smart container is as a composite application object model. These can be defined in Composer. WDK Webtop includes some generic runtime support and together these can be used for rapid prototyping.
From this demo you can hopefully extrapolate either WDK Webtop customizations adding specific runtime support for the Police Case Folders (i.e. File->New-> Police Case Folder, etc) or even a purpose built rich client bound to DFS web services, generated from the smart container model!
Anyway, here is the EDN page. I recommend you take a look. The demo is the .exe link at the bottom of the page.
Hat tip to Dave for producing this.
Happy Composing!
As I said in my opening post on the subject Composer isn’t just an application. It isn’t just a DAB/DAI replacement. It is a lot more than that. And its existence, I think, could be of great importance to Documentum and enterprise content management in general.
To understand the potential impact of this new tooling platform I want to look at the games industry and the effect their tools have had. And then examine parallels that might exist with enterprise content management and games industries.
Back in the late 70s, early 80s when personal computer capacity was small and games were simple, individuals (probably in their bedrooms) were able to design and build games all by themselves using just the operating system and knowledge of the machines’ instruction sets. Over time, as the games got more sophisticated, it took larger and larger groups of people to create them. It became a bit like a making movie. It became the domain of the game manufacturers alone pushing aside the individual contributors who could no longer afford to compete. Internally, tools emerged to help these design teams produce their games by making the production line more efficient. Then in the mid-90s the game manufacturers started including many of these tools as part of the games themselves so the people that brought the games could also customize and extend them. This extended the games shelf-life and maintained the gamers interest. The gamers didn’t have to be an employee of the games company or part of a big team. They just had to have the creativity and the desire. The tools to create where available to them.
By the end of the 90s pretty much every strategy and combat game had tools to allow you create new characters and new levels. Gamers started creating their own scenarios and passing them onto to their friends who, if they were any good, would pass them onto their friends, creating a grass roots type of movement. The manufacturers could observe these grass roots movements and where it saw significant momentum could tailor the next version of the game in those directions. A very collaborative, synergistic and mutually beneficial practice. In fact it was all very Web 2.0!
The games manufacturers had realized a couple of things. Firstly, they didn’t actually have the capacity to create every game for every gamer. And they had also realized that giving the power back to gamer was no bad thing anyway because the gamers were exactly the sort of people that would help take the games in new and innovative directions. For example, it was the grass roots movements that had dictated the rise of the WWII theme-d combat games. It was also the grass roots movements that evolved Machinima, a process whereby a game’s tools and 3D rendering engines were used, not to create new game experiences, but to create films! This movement in particular demonstrates the power of the tools & the community as this type of production could never have been imagined by authors of the tools.
Looking back on it now it is clear that a great deal of what has enabled these games and manufacturers to grow has come from the extensibility introduced by their tools. A renowned game manufacturer has stated that as much as 60% of their games could come from the community as opposed to their professional, internal design teams. Considering how big the gaming industry has become and how big analysts are predicting it will become this is of huge significance. It also means that the games manufacturers are really now competing for communities. Whoever has the most creative community will probably be the most successful.
So, back to Composer, Documentum and Enterprise Content Management. Clearly some parallels do exist. Just like games, ECM systems are large and complex. ECM solutions typically take many people, working together, to create. Composer already does and will continue to simplify this production, giving power back to our partners and customers. This should in turn lower the cost of ownership of the Documentum platform and the solutions that are created upon it. This should also help grow the Documentum community.
Also just like games manufacturers, it is literally impossible for us, or any other content management vendor for that matter, to produce every content-rich application for every customer. Again Composer comes to our rescue helping our partners and customers create the solutions that are right for them. In turn we can monitor these grass roots movements and lend a helping hand to produce vertical solutions where momentum exists.
More exciting yet is the potential for Composer to help us move ECM in new and innovative directions that can’t yet even be imagined. In the same way that game tools evolved machinima and SQL/SQL tools helped the database industry evolve whole new software industries like supply chain and document management. My hope is that the combination of standards efforts like CMIS and tools like Composer will help drive whole new software industries of our own, on top of our content management systems.
Ultimately only time will tell us what impact Composer will have on Documentum or the ECM in general. But the future looks bright. In the meantime…
Happy Composing 
In a previous post I introduced one alternative for performing integrated BOF development within Composer.
For the uninitiated, in BOF2 class loading is performed by DFC using a special class loader. This allows module (type, aspect, service, …) implementations to be stored in the Repository and served up to clients upon-demand. This allows you to leverage the power of the Content Server (version control, etc) on your Java modules. Overall this is a nice feature and it ensures you get the right behaviour for the aspects, types and services that your application uses.
However, it does complicate the development lifecycle as you have to package and deploy your modules to a development repository before you can test them. For IDE debugging this can be a nuisance.
To assist during development there is a feature built in to DFC that allows you to skip the Repository class loading step for specific modules. Let’s take a closer look.
As per my previous article create a project and within it your module.
A quick overview follows;
Now create another Documentum project to host your module’s test code. The reason we create a Documentum project as opposed to, let’s say, a regular Java project is that a Documentum project will be set up with a DFS library already on its classpath. This library contains DFC and as result is a very convenient leg-up as we are just about to create some DFC-based test code.
But first create a plain text file and call it something like bof.registry_file.properties. In the file add the following line:-
mymodule=module,my.module.MyModule
where “mymodule” is the name of your module as specified in the Module Artifact:
“module” specifies the module’s type. Other values could be “aspect”,”type” or “service”.
And “my.module.MyModule” is the fully qualified class name to your module’s implementation class. The same class name is specified in the class name field of your Module Artifact.
This file is a local module registry. You can add additional lines to suit for each module that you wish to debug in your IDE.
Next create a JUnit test case (File->New->Other->Java->JUnit-> JUnit Test Case) and add some simple test code:-
And as you will no doubt be aware for DFC to really work we need a dfc.properties file. Create a folder in the root of the project and call it something like “rsc” or “resources”. Import (or create) a dfc.properties file into this folder and make sure that it is configured with the docbroker that is hosting your test Repository. Add this folder to the project’s Java Build Path. Right-click on the project, choose Properties->Java Build Path. Select the Libraries tab and then hit the Add Class Folder… button and select the folder you just create and click OK, as follows:
Next we need to define a launch configuration. To do this, from the Menu choose Run->Debug Configurations… Select the JUnit category and then hit the New button. Give the new JUnit launch configuration a name, “BOF Test – local invocation” for example. Select the Arguments tab. In the VM Arguments field enter “-Ddfc.development.bof.registry_file=${project_loc}/bof.registry_file.properties” which sets a system property upon launch. This particular property, dfc.development.bof.registry_file, will be checked by DFC and, if set, instructs it to fulfil any request for a module that is also specified in the local registry file using a local class loader instead of its special Repository class loader. The net result is that it will load the class from your project:-
Now select the Common tab. In the Save As panel select the Shared file radio button and browse to a suitable location within this project. This will save the launch configuration in the project which means you can place it under source control in order to share it with others in your team:-
Click Apply to save the launch configuration.
I would also recommend that you create a second launch configuration, call it something like “BOF Test – Remote Invocation” and on this configuration remove the system property. Make sure you save it to the same location as the local invocation configuration. This will allow you to test in local mode or remote mode. There is good reason for doing this as I will explain shortly.
Finally, as a one-time only operation we need to install the module so that it is registered properly with the Repository. Right-click on your module project and select Install Documentum Project.
That’s it. You are now all set. To test your module. Right-click your test project and choose Debug As… (or Run As…)->Debug Configurations… Make sure the local invocation launch configuration that you created earlier is selected and hit Debug. Or simply use the toolbar short cuts buttons. Once its run. Make a change to your module’s implementation. Be sure not to install the project again and re-invoke the launch configuration. By setting breakpoints in your module implementation you will be able to see you modified implementation being executed.
This article demonstrates how to streamline the BOF development process. It also demonstrates how to create launch configurations and how to share them with your team by saving their definitions in the workspace and using source control.
One very important note. Be aware that this local invocation is really a bit of a cheat and that its usage can mask packaging problems. The fact that the class is visible in your project does not necessarily mean it will be visible with proper BOF class loading. To a large extent DFC and Composer try to negate this through the insistence of the one-time only install and through the build process respectively which catches errors. And also why I recommended creating a remote invocation launch configuration as well as a local one. But this might not stop packaging problems creeping if, let’s say, you subsequently modify your module’s packaging structure. The long and short of it is that whilst the workflow outlined here can be a real productivity boon for your developers your Documentum applications should also always go through a proper QA cycle.
As always happy Composing…
Yesterday my colleague Craig Randall, assisted by David Choy, gave a webcast on CMIS.
It was a good introduction. What it is. What it is not. Some of the use cases we think it will facilitate. The domain & data models. Relationship to DFS and a whole lot more. In case you missed it you can get the materials from here.
I’m a little late to this particular party as it all happened early PST which was a little later GMT by which time I was unfortunately otherwise occupied. And there is already a plethora of good, initial write up out there in the blogosphere from my colleagues; Craig Randall, Chuck Hollis, Cornelia Davis, Andrew Chapman. From former colleagues; John Newton. Others in the industry; Bex Huff, Laurence Hart. And of course from the analysts; CMS Watch, 451 Group, AIIM. I encourage you to check out Craig’s interview of Kyle McNabb who is the principal analyst at Forrester.
Content is were most of your organization’s high value information is kept. Just think about the thousands, if not millions of documents, slide-decks, spreadsheets, forms, PDFs, not to mentioned emails that your organization tries to manage. It is the same the world over and it is getting worse. We are generating content faster now than at any time before and this trend continues a pace. Also legal and regulatory concerns are placing more and more constraints on this content requiring it to be managed ever more intelligently, not to mentioned, requiring it to be discoverable.
But everyone knows this and has been attempting to solve the problem for a number of years. Fast forward to the present day and take a look in any typically medium to large enterprise. What you will find is a number of different types of content repository. Each of which was introduced to solve a particular piece of the content management problem; DM, RM, Web Publishing, etc. By and large they solve the problem in their domain but obviosuly each leave us with a silo of information in a repository with yet another interface. This in itself is a big problem. But with each new interface comes another skillset and therefore there is also a not an insignificant cost of ownership attached to each as well.
In short we need to start treating our content more strategically.
To date there have been quite a few efforts to standardize the ECM space but each has had its Achilles heal and none has really achieved what they set out to do, become the standard.
But I am excited about CMIS. It’s based on web services and is therefore agnostic to your client architecture. Something that JSR170 fell fowl of. It doesn’t really favour WS* or REST, it specifies both, so you can use whichever suits your needs. It is backed by us (i.e. EMC), Microsoft and Oracle as well as Alfresco, OpenText and SAP. It only exposes features already present in these vendor’s repositories. So you can have confidence that real implementations of CMIS are imminent and CMIS as a whole will have longevity.
A word of caution though. We should be realistic about the present situation. Even when adopted it’s no silver bullet in the sense that it won’t solve the silo’s problem overnight. But it could be a real enabler. Using CMIS, as the common interface for navigating content and its metadata, we can envisage solutions that allow us to index content in all of our repositories. In turn allowing us, as users, to search and retrieve that content from any repository within the organization. Or even across organizations.
It also makes the future look a lot more exciting. In the same way SQL facilitated solutions like Documentum & SAP. We are hoping CMIS will do the same for content-centric applications and solutions. This is ultimately great news for us all as knowledge workers within content-driven organizations. We will have real solutions to real problems based on the repsitories that are right for us.
Now, to help build those solutions our ISVs are going to need tools…like Composer.
Composer’s out-of-the box DFS integration is currently aimed at the Developer with simple, as opposed to advanced, requirements for DFS. Specifically, we’re talking about developers that only care about the services themselves (the basic developer) and don’t care about the package that the services come in (the advanced developer). And for a lot of use cases this out-of-the-box capability is just fine.
However, there are some other use cases where you do care about the package that the services come in. Perhaps you want to package everything in a war rather than an ear (because you use Tomcat for example). Or perhaps you want to run some additional servlets or servlet filters alongside your services (or even JSPs!). Or perhaps you have custom authentication and authorization requirements and you want to replace DFS’s authorization SOAP handler with you own.
Any of these types of requirement will mean that you care about the packaging your services come in as well as the services themselves.
Fortunately, the Java EE edition of Eclipse can help us out. It adds new projects types such as the Enterprise Application project (ear project) and the Dynamic Web project (war project). These projects will give us complete control over the contents of the ear, war & jars’s.
To compliment this it is possible to install the Composer plug-ins right into this edition of Eclipse as I talked you through here. This is a pre-requisite for this article.
With the union of these two products we can now do some cool things like create Web projects with DFS services in them. We can also significantly boost our productivity by leveraging Eclipse’s capability to deploy and test our ear and war projects on an associated application server, without having to ever leave the IDE. Eclipse supports most, if not all application servers either out of the box or via download.
To get you started I’ve created an attached a few blank templates projects which should give you the idea.
TemplateProjects1.zip contains a set of projects that will re-produce DFS’s existing packaging. It comprises an Ear project with an associated Utility project (jar project) and a War project. The utility project hosts the DFS builder and is where you would develop your services. This is also visually denoted with the Documentum logo decorator on the project icon. When exported this will produce a ear, with your service jar and an embedded war. It should look something like this:-
You’ll notice that I’ve ringed the Ear associations in red. The source file for a sample service in blue. The generated web resources for the service (the wsdl, reference web.xml, app server specific config files, etc) in green. Note these files in particular. My recommendation is that you add a custom ant-based builder that copies (or merges) these files to the relevant locations in your War file. Lastly, I’ve ringed, in pink, the DFS builder so you can see that it exists on the utility (jar) project.
TemplateProjects2.zip contains a Web project and a utility project. No ear this time. The utility project again hosts the DFS builder and is where you would do you service development. When exported this would produce a War containing a services Jar. It should look something like this:-
TemplateProjects3.zip contains a single Web project which hosts the DFS builder. This time you do everything in the Web project including develop your services. When exported this will obviously produce a single War and would contain everything DFS needs to run; the DFS runtime, JAX-WS runtime, your services, UCF, etc. It should look something like this:-
With all of these project templates you’ll notice that they are suspiciously devoid of anything DFS related at the moment; runtime, JAX-WS runtime, UCF, etc. I didn’t want to infringe any copyright’s with my employer. I like getting paid . So regrettably I will have to leave you this as a reader exercise. Another approach of course would be to import an existing DFS ear that could act as a bootstrap. It’s up to you. But obviously these files need to be applied one way or another before you can think about deploying this to a Server.
I have also left out the Documentum Core Project. Again, I didn’t want to infringe any copyright’s so before you import any of these templates make sure you have a 6.5 Documentum Core Project in your workspace. The easiest thing to do is create yourself a dummy Documentum project which will force the creation of the core project if it doesn’t exist.
OK. Assuming you have overlayed the remaining DFS files to complete your project structure. You will now want to run or debug it. First-time only you need to configure an appropriate server. In the Server’s view right-click in free space and select New->Server. Follow the wizard through to completion. Typically you will configure a new Server entry based on an existing app server installation but some of the runtimes also support installation of a new app server instance as well, Tomcat being one.
With the new Server entry created in the Servers view you now need to associate the projects you want to run with your Server. To do this you can drag them onto the Server from Package Explorer or you can right-click the project and select Run As (or Debug As)->Run On Server… or you can right-click the Server entry in the Servers view and choose Add and Remove Projects…
Once you have associated your project with your Server all that remains is to Start it or Debug it. Right-click on your server and select either Start or Debug.
Obviously if you start your Server in Debug mode (as the above screenshot shows) any breakpoints you have set in your code will cause eclipse to break into the debugger when hit.
Eclipse is very declarative in nature and most all settings are stored in special files in the project (.project, .classpath, etc) and we have tried to carry that practice on within Composer (.dmproject, .dfsproject, template, etc). So, if you want to create one of these projects yourself then it is fairly simple process, as follows:-
1. Create your web services source tree. If you want to use the DFS Builder’s defaults you must create folders /Web Services, /Web Services/src, /Web Services/bin/gen-src & /Web Services/bin/classes/.
However it is entirely feasible, and in fact probable within the context of a War or Jar project, that you will want to modify these settings so that Eclipse builds your service in the right place for your Jar or War (as I demonstrated in the with template #3). You just have to tell DFS where you want to put your files. To do this you need to edit .dfsproject file (see #2) and add the following attributes to the root element; sourcePath=”<project-relative path to dfs service java files>” (equivalent of /Web Services/src default), generateSourcePath=”<project-relative path indicating where to store generated source>” (equivalent of /Web Services/bin/gen-src default) and outputPath=”<project-relative path to compiled output” (equivalent of /Web Services/bin/classes/). The settings used for template #3 therefore looked like this:-
<?xml version=”1.0″ encoding=”ASCII”?>
<dfsproject:Project xmi:version=”2.0″ xmlns:xmi=”http://www.omg.org/XMI” xmlns:dfsproject=”http://documentum.emc.com/infrastructure/04012008/dfsproject” version=”6.5″ sourcePath=”src” generateSourcePath=”src-dfs-gen” outputPath=”build/classes” dfsSdkVersion=”6.5″>
<module/>
</dfsproject:Project>
2. Copy in the following files from a dummy Documentum project; .dmproject, .dfsproject & template. Modify .dfsproject, if required, as outlined in step #1.
3. Next, edit .classpath adding the following lines to match your DFS settings:-
<classpathentry kind=”con” path=”com.emc.ide.external.dfs.DFS_CONTAINER”/>
<classpathentry kind=”src” output=”<outputPath>” path=”<sourcePath>”/>
<classpathentry kind=”src” output=”<outputPath>” path=”<generateSourcePath>”/>
If you are outputting your source to the project’s default output folder then you can just omit the output attribute altogether.
This file determines your Java Build Path so you should be able to see these changes if you inspect the Java Build Path tab on your project’s properties dialog.
4. Lastly, edit the .project file and add the following bolded entries:-
<?xml version=”1.0″ encoding=”UTF-8″?>
<projectDescription>
<name>TemplatesProjects2Jar</name>
<comment></comment>
<projects>
<project>DocumentumCoreProject</project>
</projects>
<buildSpec>
<buildCommand>
<name>com.emc.ide.external.dfs.dfsbuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.wst.common.project.facet.core.builder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.wst.validation.validationbuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.wst.common.project.facet.core.nature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
<nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
<nature>com.emc.ide.builder.documentumNature</nature>
<nature>com.emc.ide.project.dmProjectNatureId</nature>
<nature>com.emc.ide.external.dfs.DfsNature</nature>
</natures>
</projectDescription>
Some of the other entries may be a little different, especially the natures, depending on the type of project that you are merging into.
When you save this file you should see the Documentum logo decorator added to your project and if you inspect the Builder properties tab you should also see the DFS Builder has been added.
What we have looked at today is a technique for leveraging both Eclipse IDE for Java EE Developers, specifically its WTP features, and Composer in order to develop services within the context of enterprise & web applications. This gives you as the developer complete control over the contents of your DFS package. It also allows you to leverage the full power of WTP’s server runtimes & debugging capabilities.
Happy Composing!
