Posts tagged ADEP
We are also introducing the new Adobe Digital Enterprise Platform (ADEP), which embodies multiple functionalities formerly offered by Adobe LiveCycle ES, Day Software, and more. ADEP is a bold platform, which solves a major issue emerging in modern enterprise architecture. The architectural discipline of Customer Experience Management (CEM) is important for modern enterprises to grasp and act upon. CEM is described from an architectural perspective within the blog post and video here.
ADEP offers customers many choices (such as HTML5 or SWF), which I believe is best decided on a per requirements basis. A further explanation from the Adobe website reveals some of the problems ADEP solves:
“Companies that want to differentiate themselves from the competition realize that they must deliver applications that engage customers as they access information and interact with the business and its frontline employees. And customers want access on
any device or across any channel. Central to accomplishing that goal is simple, yet engaging, interfaces that enable customers to access information and processes, even if they are contained in corporate systems. Efforts to merely extend access to such systems have not proven successful due to the complexity of user interfaces that have been designed for specialists, not customers and the frontline employees who serve them.”
The obvious enrichment a platform can deliver is a common pipeline for data and processing, designed from the bottom up with Cloud and Social Media DNA. The data modeling capabilities also offer enterprise developers some really cool new features.
Over the next few weeks we will continue to post articles to expose bits of the platform and explain what it means in terms of existing LiveCycle ES customers.
Hope to see you at Adobe MAX 2011!
Original article at http://technoracle.blogspot.com/2011/06/adobe-digital-enterprise-platform.html.
If you try to render an XFA form as HTML, chances are that you will encounter the following error: ERROR [com.adobe.livecycle.formsservice.exception.FormServerException] (http-0.0.0.0-8080-97) ALC-FRM-001-006: URI not found: /scripts/xfasubset.js Cause: scriptsxfasubset.js (The system cannot find the path specified) xfasubset.js is a BLOB … Continue reading →
Original article at http://blogs.adobe.com/ADEP/2011/09/how-to-avoid-missing-xfasubset-js-error-in-adep-forms.html.
For the developers who are working on or using Adobe® Data Services maybe already familar with Adobe® data modeling technology which is very popular and useful, it works with Data Services to accelerate the development of data-centric applications. And model-driven … Continue reading →
Original article at http://blogs.adobe.com/ADEP/2011/09/model-driven-application-development-trial.html.
As we know, ADEP has released a set of UX components in SDK. UX stands for ‘User Experience’. Reflected by the meaning, the purpose in designing these components is to bring users wonderful experience in the new platform. Task management … Continue reading →
Original article at http://blogs.adobe.com/ADEP/2011/09/introduction-to-task-management-components-in-adep.html.
Adobe LiveCycle Output ES2 lets you generate PDF documents conforming to the PDF/A (archive) ISO (International Organization for Standardization) document archival standard. Other ISO PDF standards such as PDF/X (graphic arts), PDF/E (engineering) and PDF/UA (accessibility) are not supported by Output ES2.
PDF/A has “Revision Numbers” (1 and 2) and each Revision Number can have “Conformance Levels” (“a” for advanced, “b” for basic and “u” for unicode). Revision Number “2″ is not supported by Output ES2.
More information on PDF/A standards are available at the PDF/A Competence Center.
Original article at http://blogs.adobe.com/livecycle/2011/04/livecycle-output-es2-and-pdf-iso-standards.html.
Adobe’s Ed Van Siclen talked to Sky Business News about the importance of Customer Experience Management (CEM) during a recent visit to Australia. I’ve talked to Ed on many occassions and seen him present. He clearly gets what CEM is all about and how organizations are taking advantage of the latest solutions Adobe is providing. […]
Original article at http://feedproxy.google.com/~r/MarkSzulcsBlog/~3/ji1CC5AFOSY/.
Not to long ago I had the opportunity to hear Charles Simonyi present on the topic of Intentional Programming (IP). In his presentation he discussed many of the underlying objectives and concepts that I found similar to those that we have in Business Process Management (BPM), the area where most of my experience lies. Reflecting the intentions of the developer (i.e. the business process) is the holly grail in terms of what we want to achieve in BPM, but where the “developer” is a domain expert rather than your traditional programmer. Unfortunately, the IP platform from Intentional Software, the company that Charles is a founder of, was not yet publicly available. As a result, I recently took a look at several other projects out their with similar objectives and concepts including Meta Programming System (MPS), Whole Platform, and XMF. Looking at these products naturally lead me to think much more about DSL(s), their architectures, and role in enterprise application development. At this point I’ll describe some of my high level findings to set the stage for some later postings and list some references for those interested in the topic.
1. Domain Specific Languages
A Domain Specific Language (DSL) is a specialized language engineered with the goal of implementing solutions for a particular problem domain. This is in contrast to General Purpose Languages (GPL) that are aimed at generally solving any type of problem. The key value proposition for a DSL is that is abstracts away the underlying complexities that are unnecessary for the targeted developer(s) in implementing a solution.
2. Horizontal vs. Vertical Domains
A domain is a problem space with a set of interrelated concepts. Domains can be further classified as being horizontal or vertical. In the context of DSL(s) Horizontal domains are those domains that are both technical and broad in nature with concepts that apply across a large group of applications. Examples of horizontal DSL(s) include the following (Note: I am biased towards Adobe technologies .
- Flex: An open sourced framework and DSL that targets the user interface domain by enabling Rich Internet Applications (RIA) that are portable across multiple browsers.
- Cold Fusion: A language for creating data-driven web sites.
- Document Description XML(DDX): A declarative language used to describe the intended structure of a one or more PDF(s) based on the assembling of one or more input documents.
- LiveCycle Workflow: Similar to workflow languages such as BPEL, LC Workflow is An imperative language used for specifying the interaction of a process across one or more services.
- SQL & DDL: Structured Query Language and Data Definition Language(s) are standard languages used for querying and defining data structures respectively with respect to relational databases.
- Pixel Bender: An toolkit made up of a kernel language, a high-performance graphics programming language intended for image processing, and a graph language, an XML-based language for combining individual pixel-processing operations (kernels) into more complex filters.
Vertical domains on the other hand are more narrow by nature, pertain to an industry, and contain concepts that can only be re-used across a relatively small number of similarly typed applications. Good examples of vertical DSL(s) can be found in  and are listed below:
- IP Telephony & Call Processing: A modeling language created to enable the easy specification of call processing services using telephony service concepts.
- Insurance Products: A modeling language that enables insurance experts to specify the static structure of various insurance products from which a a J2EE web portal can be be generated.
- Home Automation: A modeling language for controlling low-level sensors and actuators within a home environment.
- Digital Watches: A wristwatch language for a fictitious digital watch manufacturer that enable the building of a product family of watches with varying software requirements.
Two important points with respect to horizontal vs. vertical DSL(s) are:
- Its much easier to find examples of horizontal DSL(s) rather than vertical. This is in part due to the fact that developers are the primary contributors to new languages and creating DSL(s), which is a technical activity of itself. Its often a natural next step to look towards DSLs after establishing a successful API and/or framework that itself provides a level of abstraction
- There is overlap between horizontal and vertical DSL(s) that must be managed. In his thesis Anders Hessellund describes the general problem of managing overlapping DSL(s) as the coordination problem .
In this section we classify DSL(s) into three broad classifications based on architecture. The three classifications; Internal, External, and Language Workbench were first termed by Martin Fowler .
In our spoken languages experts typically do not invent entirely new languages to support their domain. Similarly, many argue that DSLs should be built on-top of an existing language such that its usage can be embedded in the host environment. Rather than remain true to the original syntax of the host programming language, DSL designers attempt to formalize a syntax or API style within the host language that best expresses the domain of the language.
Figure 2: Internal DSL Architecture
The syntax support of a host language constrains how expressive an internal DSL can be to a great extent. Languages with a rigid syntax structure such as Java or C# have difficulty in supporting expressive DSLs, whereas flexible (& dynamic) languages such Ruby, Python, Groovy, and Boo are designed for such support. Projects such as JMock have shown that even syntactically rigid languages such as Java can still provide fairly expressive DSL(s) by implementing method chaining and builder patterns to give the illusion of a more natural language . Fowler refers to DSLs that employ such patterns to work within the confines of a rigid syntax as fluent interfaces .
Unlike Internal DSL(s), external DSL(s) exist outside the confines of an existing language. Examples of such languages are SQL, XPath, BPEL, and Regular Expressions. Building an external DSL can be a complex and time consuming endeavour. An external DSL developer is essentially starting from a blank slate and while that may empower them to an extent, it also means that they must handle everything themselves.
So what exactly does “everything” entail? Similar to implementing a GPL, an external DSL developer must implement a multistage pipeline that analyzes or manipulates a textual input stream, i.e. the language’s concrete syntax. The pipeline gradually converts the concrete syntax as a set of one or more input tokens into an internal data structure, the Intermediate Representation (IR).
The architecture of a external DSL can still vary significantly based on its runtime requirements.
The four broad subsets of the multi-stage pipeline above as described in  are:
- Reader: readers build internal data structure from one or more input streams. Examples include configuration file readers, program analysis tools and class file loaders.
- Generator: generators walk an internal data structure (e.g. Abstract Syntax Tree) and emit output. Examples include object-to-relational database mapping tools, object serializers, source code generators, and web page generators.
- Translator: A translator reads text or binary input and emits output conforming to the same or a different language. It is essentially a combined reader and generator. Examples include translators from extinct programming languages to modern languages, wiki to HTML translators, refactorers, pretty printers, and macro preprocessors. Some translators, such as assemblers and compilers, are so common they warrant their own sub-categories.
Language Workbench & Platform
In  Fowler describes the benefits of DSL(s) versus the cost of building the necessary tools to support them effectively. While recognizing that implementing internal, rather than external DSL(s) can reduce the overall tool cost, the constraints on the resulting DSL can greatly reduce the benefits, particularly if you are limited to static typed languages that traditionally have a more rigid syntax. An external DSL gives you the most potential to realize benefits, but comes at a greater cost of designing and implementing the language and its respective tooling. Language Workbench’s are a natural evolution that provide both the power and flexibility of external DSL(s) as well as the infrastructure (IDE, frameworks, languages, etc…) to greatly facilitate the implementation of the necessary tooling for the DSL. In the picture below we expand upon the concept of a Workbench to a Language Platform, which includes not only the Workbench but also the Runtime for the implemented languages as well.
The concept of a Language Workbench (or Platform) is relatively new. Much of initial theoretical work in this area was started by Charles Simonyi with the concept of Intentional Programming, which he started at Microsoft  and the work being done by his later company, Intentional Software. For purposes of this posting we will discuss two important aspects of Language Workbenches shown in the illustration above.
Multi-level Projection Editors
A projection editor is an editor for the concrete syntax of a language, whether that syntax is textual or graphical. These editors are tightly bound to their respective languages and offer the assistance capabilities which we now expect from modern editors such as code completion. Unlike, traditional free format text editors, projection editors can:
- work directly with an underlying abstract representation (i.e. an Abstract Syntax Tree)
- can bypass the scanning and parsing stages of the compiler pipeline
- direct users to enter only valid grammatical structures
- can be textual or graphical
- can offer multi-level representations that abstract out various views of the program for various users and enabling multi-level customizations of the end solution 
Its long been realized that compilers & interpreters are typically unable to take advantage of domain specific context encoded within the source code of a GPL. Moreover, as discussed previously DSL(s), both internal and external, often lack tooling support or acquire it through significant costs. Active Libraries enable DSL developers to overcome the overall lack of domain-specific tooling by taking an active role throughout the language tool chain, from the IDE, through the compiler, to the runtime. The are three types/levels of Active Libraries :
- Compiler Extensions: libraries that extend a compiler by providing domain-specific abstractions with automatic means of producing optimized target code. They may compose and specialize algorithms, automatically tune code for a target machine and instrument code. Czarnecki et al provided Blitz++ and the Generative Matrix Computation Library as two examples of libraries that extended a compiler with domain specific optimizations.
- Domain-Specific Tool Support: libraries that extend the programming environment providing domain-specific debugging support, domain-specific profiling, and code analysis capabilities, etc… The interaction between Tuning and Analysis Utilities (TAU), a set of tools for analyzing the performance of C, C++, Fortran and Java programs and Blitz++ are good examples.
- Extended Meta-programming: libraries that contain meta-code which can be executed to compile, optimize, adapt, debug, analyze, visualize, and edit the domain-specific abstractions. Czarnecki et al  discuss active libraries generating different code depending on the deployment context providing the example that they may query the hardware and operating system about their architecture.
For my purposes I was primarily interested in the domain-specific tool support afforded by active libraries (i.e. #2 above). In the case of Language Workbench’s we are looking for domain specific support for rendering, editing, re-factoring, reduction(i.e. compiling), debugging, and versioning capabilities.
4. Role of the Language Engineer
While the concept of DSL(s) and Unix “small languages” have been around for some time, the focus has been on slowly evolving General Purpose Languages (GPL). As a result, the industry currently lacks developers, patterns and best practices, as well as tooling that facilitate the design, implementation, and evolution of languages on a larger scale. Language Engineering is a more complex activity than typical software and system engineering. In-order for the benefits of DSL(s) to be fully realized there needs to be a new discipline evolved that focuses on engineering of domain specific languages. Similar to others  this paper asserts that there will be a paradigm shift that demands the creation of a new role, the Language Engineer, in the software development process. Furthermore, the creation of this role will significantly reduce the workload of application developers in building a given solution in a similar fashion to the introduction of 3rd generation languages and subsequently platforms (e.g. Java/J2EE and .Net).
While we would not expect to see the dramatic increase in productivity that we saw with the introduction of 3rd generation languages, we would still expect the productivity increases to be substantial once effective tooling is in place for both the Language Engineer and the Application Developer as the consumer of any given DSL.
5. Benefits & Costs
In this section we review & summarize many of the costs and benefits associated with creating and using domain specific languages.
Benefits of DSL(s):
- Domain Knowledge: Domain specific functionality is captured in a concrete form that is more easily and readily available to both application developers, who are direct language users, and domain experts. The benefit of capturing domain knowledge can be realized throughout an applications life-cycle.
- Domain Expert Involvement: DSLs should be designed to focus on the relevant detail of the domain while abstracting away the irrelevant details making them much more accessible to domain level experts with varying levels of programming expertise. In cases where there is already an existing notation understood by the domain expert the DSL should be designed with a concrete form to match that existing notation. For example, for users familiar with the Business Process Modeling Notation (BPMN), a related Workflow DSL should enable users to implement workflow solutions using familiar BPMN constructs.
- Expressiveness: DSL’s that are tailored to a specific domain can more concisely & precisely represent the formalisms for the specified domain. Furthermore, DSLs tend to be declarative in nature, enabling the developer to focus on the “what” while eliminating the need for them to understand or over specify their program with the “how.”
- Compilation & Runtime Optimizations: As discussed with Active Libraries the additional context afforded DSL(s) can provide for domain-specific optimizations at either compile and/or runtime. Adobe’s Pixel Bender language is an example of a language designed to provide optimizations by leveraging parallelization on multi core machines. Similarly, there are many use cases in the scientific community where DSL’s have been leveraged for abstraction and optimization to handle sparse arrays, automatic differentiation, interval arithmetic, adaptive mesh refinement, etc… – The expressiveness of DSLs not only eliminate the need for developers to over specify their code, but consequently provides more opportunity for the infrastructure to intelligently optimize where and when possible.
- Re-Use: Due to the additional costs associated with designing and supporting DSLs mentioned previously DSLs should not be created for isolated solutions. However, in cases where a problem in a particular domain (horizontal or vertical) is repeating there is ample benefit to be gained by re-using the expressiveness of DSLs and the other benefits that follow.
- Reliability: Like libraries once tested DSL(s) provide higher level of reliability when re-used across projects.
- Toolability: By associating a concrete and abstract syntax to a language, such as is the case with External DSL(s) or DSL(s) defined in a Language Workshop, tools are better enabled to analyze and provide guidance through assistance or verification tooling.
Costs of DSLs:
- Tool Support: One of the primary benefits of creating DSL(s) vs. application libraries is the ability to add tooling based on the concrete syntax of the DSL, however today such tooling does not come for free, it must be built as part of the cost of creating the DSL. Tooling features include features such as code guidance/assistance, re-factoring, and debugging.
- Integration: The successful development of most applications today requires the convergence of multiple views. Business analysts, domain experts, interaction designers, database experts, and developers with different types of expertise all take part in the process of building such applications. Their respective work products must be managed, aligned and integrated to produce a running system .
- Training Cost: As opposed to mainstream languages, DSL users will likely not have an established specification to look to for guidance. However, this cost can be offset by the degree to which the DSL narrowly reflects and abstracts the domain concepts.
- Design Experience: DSL platforms are not yet widely adopted in the software industry. As a result, there is an evident lack of experience in the field around language engineering, language design patterns, prescriptive guidelines, mentors, and/or research.
Anyway, hope to have some more postings related to DSLs in the not to distant future. At this point I am attempting to pull together a lot of good ideas from various areas. Which reminds me here is the list of docs referenced throughout this posting.
 T. Veldhuizen and D. Gannon, “Active Libraries: Rethinking the role of compilers and libraries,” page 2
 A. Hessellund. “Domain-Specific Multimodeling,” Thesis. IT University of Copenhagen, Denmark. page 15.
 S. Kelly & J. Tolvanen, “Domain-Specific Modeling,” John Wiley & Sons, Inc. 2008, Hoboken, New Jersey.
 S. Freeman, N. Pryce. “Evolving an Embedded Domain-Specific Language in Java,” OOPSLA, Oct 22-26, 2006, Portland, Oregon, USA.
 T. Parr, “Language Design Patterns, Techniques for implementing Domain Specific Languages, ” Pragmatic Bookshelf, 2009. pages 14-16.
 K. Czarnecki, M. Antokiewicz, and C. Kim. “Multi-Level Customization in Application Enginneering, ” Communications of the ACM, Vol I, December 2006. pages 61-65
 C. Simonyi. “Intentional Programming – Innovation in the Legacy Age, ” Presented at IFIP WG 2.1 meeting. Jun 4, 1996
 K. Czarnecki, U. Eisenecker, R. Gluck, D. Vandevoorde, and T. Veldhuizen. “Generative programming and active libraries (extended abstract). ” In M. Jazayeri, D. Musser, and R. Loos, editors, Generic Programming ’98. Proceedings, volume 1766 of Lecture Notes in Computer Science, pages 25–39. Springer-Verlag, 2000.
 Meta Programming System, http://www.jetbrains.com/mps/index.html
 T. Clark, P. Sammut, J. Willans. “Applied Metamodeling A Foundation For Language Development, ” Ceteva 2008.
 R. Solmi. “Whole Platform, ” Thesis for Department of Computer Science at University of Bologna. Italy. March 2005
 B. Langlois, C. Jitia, E. Jouenne. “DSL Classification,” In 7th OOPSLA Workshop on Domain-Specific Modeling, 2007.
 OMG, Meta Object Facility (MOF) 2.0 Core Proposal, ad/2003-04-07, 7 Apr 2003.
 A. Kleppe. “Software Language Engineering.” Addison-Wesley Professional. 12/09/2008. Page 19.
Original article at http://lostintentions.com/2009/08/15/a-look-into-domain-specific-languages/.
About 3 years ago I wrote my first custom component for Adobe LiveCycle ES, a Twitter client, that allowed you to Tweet as part of a process orchestration. I’ve seen it crop up in quite a few demonstrations over time and find it to be a good example of how extensible Livecycle ES is. Until […]
Original article at http://feedproxy.google.com/~r/MarkSzulcsBlog/~3/B91CLZMA-IY/.
First, an elementary explanation of what it is: JGroups is a toolkit that is used in LiveCycle to broadcast group based messages in a controlled infrastructure which by default leverages multicast as a communication mechanism. A much more defined and thorough explanation can be found at jgroups.org. This post is intended to provide some insight into how JGroups is used in LiveCycle ES and ES2 at a somewhat lower level and explain some of the configuration parameters. This post is not intended to be a “how does JGroups work” article.
It is important to note that JGroups is used in other areas of a LiveCycle infrastructure:
- Gemfire (which LiveCycle uses as a caching solution)
- Content Services
- 3rd party application servers that host LiveCycle
This post will only touch upon how JGroups is used in LiveCycle Workspace.
LiveCycle Workspace is a Process Management component that provides a web-based user interface that lets users participate in business process activities. When a user is logged in to the Workspace client, that user has to be kept up to date with any activity that involves them, so the use of LiveCycle Data Services is employed as a communication layer between that client and the server. At any time that an event is triggered that would impact the content being displayed to an end user, that information must be broadcast to the data services layer of LiveCycle Workspace, this is where JGroups comes into play.
Getting into more specific detail, JGroups is used to push internal LiveCycle events, such as task creations, task reassignments and task completions out to the Workspace web application (Workspace WAR). These LiveCycle events will be presented to users logged into Workspace as a toast message indicating what has been added, removed or changed for that particular user.
So, how does LiveCycle Workspace use JGroups?
When a LiveCycle event occurs from TaskManager, a component called the RemoveEventDSC contains a JGroups broadcaster that will use multicast to send a message intended for the JGroups listeners in the Workspace web application. Every instance of the Workspace web application will have a listener where it is set up to only consume messages for which it is intended. When a message is consumed by the JGroups listener in the Workspace server component, an update is made to the data services layer, the updates are consumed when that layer is next polled by the Workspace client.
JGroups has a number of configuration parameters that can be changed to accommodate various infrastructure restrictions. All configuration parameters are setup in an XML file which you have to first export using AdminUI, make appropriate changes, re-import and then restart your LiveCycle environment. Here’s where you can get that XML file: Login to AdminUI as an administrative user, click on Services, then click on LiveCycle Workspace ES2 and finally click on Global Administration, the last button on the screen is for exporting the global settings. Click on that button, it will generate an XML file that you can save locally to work on it. Make a backup of the file before making any edits.
In the XML file (AdminGlobalSettings.xml) that you exported, there are 2 items that are relevant to JGroups settings:
This is the name of the JGroup that is used for broadcast message consumption; the value stored in this setting is auto-generated and unique for each new environment. The only time you would ever change this value is if you copied a LiveCycle database environment to create a new LiveCycle environment.
Generally the settings found in this element are valid for most networks, however in some cases some of the settings need to be tweaked to accommodate stricter network policies.
Some examples of elements that “could” be changed:
mcast_addr: (Multicast address) – some subnets require a specific IP address range where multicast is permitted; you have to ensure the network IP Address used for multicast is valid for your topology. As an FYI, IPv4 multicast has a range of 184.108.40.206 to 220.127.116.11.
mcast_port: (Multicast port) – as with the IP Addressed used, the port must be available for the subnet where LiveCycle is running. Generally the port number is rarely an issue to affect connectivity; however each network is different, so if communication issues are encountered with an error connecting on the port specified, you should talk to your network administrator to figure out what port to set.
FD: (Failure Detection) – JGroups has built in failure detection; the timeout setting here says it will wait 3 seconds for a response from an “are you alive” message to another JGroup node. If the response is not returned within 3 seconds, a second message is sent, called a “suspect” message (explained next) – You can increase the timeout setting to beyond 3 seconds, but be warned that if failure detection is happening, it means there’s likely something in your network slowing down communication which should be addressed.
VERIFY_SUSPECT: This is a secondary check if the Failure Detection timeout is reached. Only when a FD limit is hit will this second attempt be run to double-check if a member is really not responding. Think of this setting as a means to ensure that a detected failure is really failed by trying again. You can also increase this value, but also be warned that addressing the actual cause of the unresponsive node is more important than increasing a timeout.
There are other settings in the file that should not be altered, if you are curious I suggest visiting jgroups.org for details on the specifics on those additional elements along with any other JGroups specific details you are looking for.
Original article at http://blogs.adobe.com/livecycle/2011/03/jgroups-and-livecycle-workspace-explained.html.
When configuring LiveCycle ES2 using LiveCycle Configuration Manager, you have to provide SOAP port of your WebSphere application server on some LiveCycle Configuration Manager screens. Follow the steps below to determine which port is used for SOAP connections with your WebSphere application server. The default port, however, is 8880.
To determine the SOAP port on WebSphere Base:
- In the navigation panel of the WebSphere Administrative Console, do the following:
- (WebSphere 6.1) Click Servers > Applications Servers > [serverName] > Communications > Ports.
- (WebSphere 7) Click Server Types > WebSphere application servers > [serverName] > Communications > Ports.
- Under Communications, click Ports. On the next screen, make a note of the port number for SOAP_CONNECTOR_ADDRESS.
To determine the SOAP port on WebSphere Deployment Manager:
- In the navigation panel of your WebSphere Administration Console, click System Administration > Deployment Manager.
- Under Additional Properties, click Ports. On the next screen, make a note of the port number for SOAP_CONNECTOR_ADDRESS. The WebSphere Administrative Console lists the SOAP Connector Address in two different sections. You must ensure you use the path provided in step 1 for WebSphere Deployment Manager. If you use the SOAP port listed at Servers > Application Servers > [serverName] > Communications > Ports, you will see the following error when running LiveCycle Configuration Manager:
com.adobe.livecycle.cdv.util.JaclResponseParser, parseString: WASX7017E: Exception received while
running file "..scriptsjaclconfig.jacl"; exception information: com.ibm.ws.scripting.ScriptingException: WASX7070E: The configuration service is not available.
For more information on IBM WebSphere, click here.
Original article at http://blogs.adobe.com/livecycledocs/2010/11/determining-soap-port-websphere.html.