Theo van Kraay

Ranch Hand
+ Follow
since Nov 06, 2015
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Theo van Kraay

Absolutely none. The fact that Spark is able to run over Hadoop was done merely for backwards compatibility as Hadoop was the 'big thing' in distributed processing at the time. In 'standalone mode', Spark can actually run over any distributed file system... it doesn't have to be Hadoop.
7 years ago
p.s. I have assumed that you know what to do to correct the compiler (i.e remove the wildcard and just declare Student as the generic type) and I have also assumed that your question relates to the confusion I elaborated on above (please correct me if I was wrong in those assumptions).
Interesting question. I am NOT 100% certain about my answer, but it makes sense to me, and since this has been up for a day and I guess you are preparing for the exam, I will offer it anyway. You can either take my logic at face value, or you can wait for someone who is certain (though they may not necessarily be correct!) to validate it (I do advise the latter) :-)

I presume the reason you are surprised by this is that you thought because lower bounded wildcards don't render corresponding assigned objects immutable, it should not cause the problem that it does? I think the issue here is nothing to do with those rules around immutability, but that there has to be equality on either side of the expression where generics are declared (or diamond operator must be used on the right hand side to allow Java to infer the types).

In other words, you could think of your code as doing something like the following:



Clearly this will not compile because the generic types on either side don't match. I appreciate that in your actual code you are not doing a normal assignment with generic types declared on the right hand side etc, i.e. you are using a stream, but the point is that Java still knows that the generic types in the resulting assignment don't match. The fact that there are different rules around immutability between different types of wildcard is irrelevant.
I don't understand this requirement. Exactly why do you need to logon to the Windows box programmatically? What technical/user requirement is this facilitating? Is the tomcat server on the same windows box or on a remote server? This needs more clarification. Thanks.
8 years ago
No plans from Oracle to replace the OCMJD. See comments section at Oracle site here:

https://blogs.oracle.com/certification/entry/oracle_certified_master_java_se

In fact skills required for OCMJD are, apparently, considered by Oracle to have been subsumed into the Programmer Certifications as of Java 8 exams:

"At this time, there is no plan to release a new version of the certification. Through careful job task analysis with the Java SE 8 certification release, it was determined that the OCM Developer role was no longer appropriate to keep as a separate certification and the that skills of that role should be included in the Programmer certifications."
8 years ago
Hi Cathal. I was reading this thread, which I realise is quite old, to try and gauge what OCMJEA is all about. I'm wondering whether your opinion on Java, and Oracle in particular, has changed in the  4 years since your last post? They seemed to have a dodgy start, but it seems like Java 8 has been a great success to me.
...and of course, I found the answer on the Oracle forum (in case anyone else was wondering):

"At this time, there is no plan to release a new version of the certification. Through careful job task analysis with the Java SE 8 certification release, it was determined that the OCM Developer role was no longer appropriate to keep as a separate certification and the that skills of that role should be included in the Programmer certifications."

From my point of view, it's a little disappointing, but it is what it is.
Hi there. Would be helpful if you could first summarise what you know already, e.g. what your background is, what software paradigms you understand already and what you know of SOA and ESB so far etc, so that I'm not trying to teach you to suck eggs or pointing out resources that are not necessary. Also, your motivation/need for learning might help.
8 years ago
From what you write, the proposal to use JMS as a mediator would make sense if:

1. the REST web service container itself is locked down and cannot be horizontally scaled any further.

AND

2. The REST web service layer isn't adequately scaled to cope with volumes that your interfacing application will handle.

Of course, the far better thing to do in most circumstances (unless  the web service container is particularly intolerant to downtime from a business/non-functional perspective) is to just scale out the web service layer without introducing JMS. However, taking point 1 as a given, it sounds like someone has then made the judgement call on point 2.

Again, there isn't anything intrinsically specially about REST (anymore than there is about any other website - see earlier comment) such that this screams "unnecessary". If the REST container's topology really can't cope with the volumes of the consuming, you of course need to either scale out or offset the load. By the same token, there isn't anything especially "fragile" about REST either. Its just a client/server container like any other but with the specific function of providing technology stack agnostic API container available through the RESTful service.

How have the person/team demonstrated/proven that the REST container isn't adequately scaled, such that the JMS mediator is necessary? That would be my question.
8 years ago
Your question is pretty generic but I will try to give an answer and if it is too verbose or off the mark I will probably need more specific questions.

Firstly, the volume/capacity of any web service (as you've noted) is not so much a function of the type of web service it is (i.e. SOAP, REST, RPC, POX, etc) as much as the topology (architecture) on which the service is built (e.g. multi node, multi core, load balancer, highly-available, etc, etc.). A REST web service will not very much more volume than any other type of service if it is running on low powered physical or virtual hardware, just like any other type of web-based architecture.

That being said, RESTFul web services are gaining popularity over the more traditional style of web services (SOAP has been the most popular protocol in last 10-15 years), and one of the reasons for that is that they are much more lightweight than SOAP web services with a lot less redundancy. As such, they are quite well suited to high volume, low latency "micro service" API (a separate topic in its own right). The trade off is that they don't provide the rich metadata and "transport agnostic" messaging paradigm that is embedded in SOAP. Some will argue that in a http cloud-only world, that doesn't matter. I personally think it does, and REST web services are in many ways to SOAP what NoSQL database engines are to RDBMS - they are an alternative, not a replacement.  

A side note, but it is important (to me, at least) to note here that REST (or "representational state transfer") is actually not a unique acronym for "web services", but it is in fact the term that describes the architectural style of the web; all interaction that uses TCP/IP (HTTP) is, technically, implementing the REST pattern (in other words, every website in existence, including this one, implements REST). However, the term has been hijacked and somewhat narrowed to describe a certain type of web service that is tightly coupled with HTTP , and typically uses JSON format for request/response message payloads. As such, some caution is advised when you hear "REST vs SOAP" - technically this is not comparing apples with apples and can be misleading.

RE your question on exact numbers, I cant give you that as it depends on far too many factors: size of payload, processing speed, business logic, etc. But it is certainly true to say that you can gain performance improvements over using SOAP/XML based messaging, by implementing a RESTFul style with JSON.
8 years ago

Stephan van Hulst wrote:

Jude Niroshan wrote:Most important fact that I learnt was, even though accumulators may run in parallel, combiners will always run sequentially which they were appeared to be in the List.



This is NOT true. Combiners will combine partial reductions as if all elements were reduced in order, but this process still occurs in parallel. That's why the combiner function needs to be associative and stateless.

Let's say you have a stream [1,2,3,4,5,6] and at some point during the reduction you end up with three partial reductions [1,2,3], [4] and [5,6] that need to be combined. It's perfectly legal for the reduce function to first combine [4] and [5,6] before it combines [1,2,3] with [4,5,6].



To be honest, I kind of thought this is what Jude meant (though I agree the language/wording does imply that the combiner will run sequentially). I think she just meant that the combiner will always ensure that items are ultimately combined in the order they first appear in the list (which they will, as long as the function is stateless and associative which is an important point). Perhaps I gave too much latitude, so your clarification was certainly very worthwhile
Hi there. I know this question was posted a while ago but will add my response. I think the key bit of information in the standard is here:

"Web Services Addressing (WS-Addressing) defines two interoperable constructs that convey information that is typically provided by transport protocols and messaging systems. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application. The two constructs are endpoint references and message information headers."

However, I understand why this might still seem a bit nebulous. To illustrate, one common implementation of the standard (and one I have used) is in the development of asynchronous "call back" web services. This is kind of analogous to the pub/sub model in JMS. If you have used queues and JMS, you might be able to see the pattern; caller provides a message ID and request URI information (the latter is then used more for message auditing, and/or routing), and also provides a "replyTo" endpoint where the asynchronous response message can be submitted (and handled by the original caller). The URI information from the caller may be important, for example, because it might not actually be the endpoint of the responding service, but of a mediator that has handled the routing. Bear in mind that SOAP is not just a messaging protocol; a number of the SOAP standards have to do with wider SOA goals around loose coupling, service mediation, routing and orchestration. This is in part what is meant by "transport neutral"; SOAP is trying to provide a technology agnostic and transport neutral mechanism in a Service-oriented architecture (which is why SOAP is sometimes called the "language of SOA", though RESTful/JSON web services can also meet those goals).

I don't know if my description was the best but I hope it makes some kind of sense.
8 years ago
Hello there. Looks like you posted this 4 months ago, so I am guessing you got your answers. If not, let me know. Its an area I have interest/experience in, so may be able to point you in the right direct, etc.
8 years ago
Martin did you find anyone to do this for you?
8 years ago