"MicroEdition-Profile" can have multiple values separated by space in the JAD file, where as "MicroEdtion-Configuration" can have only one value.
According to JTWI specifications,
Minimum requirement for MIDP is 2.0, so this gives us only one option (MIDP 2.0) to put in the JAD file
Minimum requirement for CLDC is 1.0, so this gives us two options to put in the JAD file ie: CLDC1.0 and CLDC2.0
I can create an application which is compatible with CLDC1.0 and 1.1. Why are multiple values allowed for Profile attribute but only one value is allowed for Configuration attribute?
MicroEdition-Configuration refers to the lowest-level part of the system - the JVM and so on.
MicroEdition-Profile gives a list (often of size one) of the additional software environments on top of the configuration (application lifecycle, UI etc.)
For more info see A Survey of Java ME Today (actually from 2007, but a useful overview still):
A configuration, at the bottom of the
Java ME organization stack, defines a
basic lowest-common-denominator Java
runtime environment. This includes the
VM and a set of core classes derived
primarily from the Java SE platform.
Each configuration is geared for a
broad family of constrained devices
with some type of network
connectivity.
And on profiles:
Configurations do not provide classes
for managing the application life
cycle, for driving the UI, for
maintaining and updating persistent
data locally in the device, or for
accessing securely information that is
stored on a network server. Instead,
that type of functionality is provided
by the profiles or by optional
packages. A profile adds
domain-specific classes to the core
set of classes provided by the
configuration, classes that are geared
toward specific uses of devices and
provide functionality missing from the
underlying configuration.
MIDP is the most common profile for mobiles, but there are others: IMP - a kind-of headless version of MIDP (JSR-195); and DSTB for digital TV (JSR-242).
Related
My deployment diagram has a device with a Windows ExecutionEnvironment in it. The application uses several dynamically loaded libraries, some of which are deployed with the application, others into the system itself.
How are dynamically loaded libraries normally represented in deployment diagrams?
My current theory is my application gets its very own execution environment within the Windows where I deploy my application specific dynamically loaded libraries, and have the system libraries deployed outside it:
For above diagram the system has v1 of libraryA and libraryB installed, and v2 of libraryA is deployed with the application, shadowing the system version.
Your approach makes perfectly sense:
ExecutionEnvironments represent standard software systems that application components may require at execution time.
Moreover:
Artifacts elaborate and reify the abstract notion of DeployedArtifact. They represent concrete elements in the physical world, may have Properties representing their features and Operations that can be performed their instances, and may be multiply-instantiated so that different instances may be deployed to various DeploymentTargets, each with separate property values.
This applies perfectly to dynamic libraries, where there is one library loaded by the OS and that may be used by multiple applications, each in its own address space.
Some hints:
You could use the «Library» and «Executable» stereotypes of the UML standard profile to better distinguish different kind of artifacts.
You could add the dependency from the executable to the required libraries
I am attending a training course where they presented the following graphic as the Anatomy of a Typical Java Web Application. Is it too sweeping of a statement, or is it largely accurate?
Here it goes:
(Disclaimer: My experience is drawn mostly from non-Java platforms, though I have some limited experience with Java - but mostly I'm not a fan)
It's accurate - but only for applications using that architecture - which makes this statement somewhat of a tautology.
I'll break it down:
Service Consumer Perspective
A "service consumer" is also more commonly known as a client.
"Service interface files" are not needed to build a client.
I assume by "interface files" it's referring to things like a SOAP WSDL document or Swagger file for REST services. These files are not generally used by clients at runtime but are used to automatically create client class-libraries at design-time - but you can always build a client without any code-generation or reuse of Java interface types.
If it is referring to the reuse of the server/application's Java interface types then the diagram is only accurate for client+server applications that are all-Java and are both designed/created at the same time (which is an old practice from the days of SOAP). Thesedays everything made in the past 5-10 years is RESTful and returns JSON data, but Java interface types are insufficient to model unstructured data like JSON (given you can't model discriminated-unions without concrete classes... in exception handlers, egods, and discriminated-unions are an important tool to model JSON in OOP languages).
Service Provider Perspective
I disagree with the use of the term "Front controller" being used to refer to what is commonly known as a back-end web-service controller, Servlet, or Spring Controller as "front-end" generally refers to the user-facing UI/UX, such as the rendered HTML+JS, an SPA front-end, or rich-client/fat-client (granted, this would be the "service consumer").
You don't need "service metadata" to have a web-application or a web-service - though if you're shipping a web-service designed to be consumed by disparate or non-first-party clients then its a good idea to make a WSDL, Swagger, or whatever metadata or service-description system your platform uses so that your consumers can generate their own strongly-typed clients.
"Service implementer perspective"
So this is my biggest objection: this diagram assumes that the web-service will be 3-tier and the controller/Servlet code is only a thin layer in front of "application" types located elsewhere in the system. While this is common in large-scale and complicated applications where you'll have host-agnostic application code that is designed to be able to run in, for example, an integration-test or unit-test host - or as a desktop application, in my experience I estimate most projects lump all application logic inside the host-specific (i.e. Spring, Servlets, etc) code because it simplifies things greatly (and because those hosts often support testability anyway - and the idea of reusing application code libraries as-is for desktop or mobile applications just doesn't work out well in reality given the massive differences between the disconnected and stateless model of web-service requests compared to the needs of stateful in-process client applications).
In summary: it's not wrong, but I don't believe it accurately describes the majority of (Java) web-applications I've personally dealt with... but this is my subjective opinion and I know that Java web-application and web-service frameworks like Spring and Java EE are designed for and encourage 3-tier architecture, I wouldn't describe them doing-so as an example of the pit-of-success - I feel this is partly due to shortcomings in the Java language design (and the fact these frameworks were designed over 20 years ago before things like generics were added to the language).
I just noticed this project at Apache OpenCMIS:
https://svn.apache.org/repos/asf/chemistry/opencmis/trunk/chemistry-opencmis-bridge
There is no description, no documentation, and reading the code does not give many hints about what it is supposed to do.
Apache OpenCMIS sometimes releases great software silently, with little communication, so we might be missing another great piece of software here.
A Google Search for "OpenCMIS Bridge" returns only source code and the bare download page.
The OpenCMIS Bridge works like a proxy server. It accepts CMIS requests and forwards them to a CMIS server. On the way it can change the binding, and filter, enrich and federate data.
Here are few use cases:
If a repository does not support the CMIS 1.1 browser binding, you can put the OpenCMIS Bridge in front of it. The bridge then could talk JSON to the client and AtomPub to the server. The client wouldn't notice that the server doesn't support the browser binding.
Code can be added to the bridge to redact property values or filter whole objects when they are transferred through the bridge. That could add another level of security that the native repository doesn't support.
Code can also be added to add or enrich object data. For example, property values could be translated from cryptic codes into readable values. Virtual secondary types can be added on the fly. Or additional renditions could be provided.
The bridge can also be used to provide different views of multiple repositories. Repositories of different vendors can be access through one unified endpoint. It's possible to build one virtual repository across multiple backend repositories that then, for example, allows a federated query across all backends.
The OpenCMIS Bridge is only a framework, though. It just provides the infrastructure and the hooks to add your own code and rules.
If you are looking for a real world application, check SAP Document Center (formerly "SAP Mobile Documents"). It is based on the OpenCMIS Bridge.
I'm a Java newbie. Wanted to know if all Java SE classes are available in Java ME. If not why is it so?
No, only a subset is available, see http://java.sun.com/javame/technology/index.jsp for an introduction.
A brief overview is given in this Wikipedia article:
Noteworthy limitations
Compared to the Java SE environment, several APIs are absent entirely, and some APIs are altered such that code requires explicit changes to support CLDC. In particular, certain changes aren't just the absence of classes or interfaces, but actually change the signatures of existing classes in the base class library. An example of this is the absence of the Serializable interface, which does not appear in the base class library due to restrictions on reflection usage. All java.lang.* classes which normally implement Serializable do not, therefore, implement this tagging interface.
Other examples of limitations depend on the version being used, as some features were re-introduced with version 1.1 of CLDC.
CLDC 1.0 and 1.1
The Serializable interface is not supported.
Parts of the reflection capabilities of the Java standard edition:
The java.lang.reflect package and any of its classes not supported.
Methods on java.lang.Class which obtain Constructors or Methods or Fields.
No finalization. CLDC does not include the Object.finalize() method.
Limited error handling. Non-runtime errors are handled by terminating the application or resetting the device.
No Java Native Interface (JNI)
No user-defined class loaders
No thread groups or daemon threads.
It's worth noting that where J2ME versions of J2SE classes are apparently available, they often have a reduced API. So you can't always assume that code using 'available' classes will port straight over.
If memory serves, there are one or two methods with differening names too. Memory doesn't serve well enough right now to recall a specific example.
No, Java ME is a significantly restricted subset of Java SE. Java SE is an enormous standard library, and most of the devices Java ME is intended to run on don't have the resources to support all that overhead.
Take a look at the javadocs for CLDC 1.1, the main, universally supported API accessible to Java ME.
No they are not. The reason for this is the standard library is quite large, making it difficult to use on embedded devices with small amounts of memory and slower processors.
See this page for more info about whats included and whats not.
Recently, I've become quite involved experimenting with lightweight grid frameworks (Hazelcast, Gigaspaces, Infinispan).
However, I've been somewhat surprised than none of the free frameworks I tried has any ACL or role based security features built in (Gigaspaces does have some measures).
What approaches are generally used to compensate for this? Am I supposed to only use the grid to share data between trusted server-side applications and use the traditional Java EE stack (i.e. a conventional DAO-layer) to access data from client or non-trusted server applications?
Are there any grid frameworks that provide ACL capabilities for accessing data in the grid (I'd be happy with some ad-hoc stuff, although complying to Java EE role concepts would be nice)?
This is my opinion on current state of open source distributed cache solutions (e.g. JBoss Cache and Infinispan). As a baseline I am using GigaSpaces commercial caching product. Let me know what you think about open source and proprietary cache products.
read more at: http://bigdatamatters.com/bigdatamatters/2009/09/infinispan-vs-gigaspaces.html